Wow, I was not aware of this weird Layout offered by Logback
. It's basically a Layout that tries (but clearly fails) to mimic the Log4j XML Layout. I personally think it's wrong that Logback provides this. If at least it had the same format, why not, but since it's not the same format, I wonder what the point is. And even if at some point the 2 formats are the same, they can easily fork since it's 2 different projects (maybe that's what happened). Ironically, this Logback layout seems to be written by Ceki Gülcü, the author of both Log4j and Logback...
Anyway, I don't think that LogMX will ever have a built-it Parser for this weird layout, because we are trying to ship LogMX with only the most common log formats to avoid having too many Parsers, because the more Parsers you have, the longer it is for LogMX to detect the format used in your logs.
You made a good point concerning the XML entity ' but it's actually on purpose that LogMX doesn't decode any kind of XML entities, for performances reasons. It's actually also for performances reasons that adding a new line between 2 XML elements prevents LogMX from recognizing this format: it doesn't use a proper XML parser for better performances. When we built the first XML Parsers, we had way better performances using our own code compared to the fastest available XML parsers (and also because most of XML parsers don't work well with invalid XML content, like it's sometimes the case with logs being currently written without being able to close the root element, or when log file is rolled).
But in general, I would not recommend using XML to write logs in the first place: log files are huge, not easily readable by humans, and have a serious performance hit when trying to analyze/parse them.
Anyway, if you still want to use this layout, the Parser I gave you in my last message should work just fine. Did you have any trouble with it? (well except for XML entities