On Apr 27, 2005, at 12:21 PM, Dave Pawson wrote:

The XMLLayout works fine for me although it is not the most human readable
xml!
Errr yes. I'm taking your advice and subclassing that. First thing will
be to remove the CDATA sections!



I'm not fond of the CDATA sections either. Since the XMLLayout is not aware of the encoding of the writer, it does not know when to create character entities. My preference would be to use character entities for markup characters or any non-USASCII character which would eliminate the need for the CDATA sections and would allow the log to still be readable in case an editor assumes ISO-8859-1 and the document is UTF-8 or vice-versa. There is a decent likelihood for XMLLayout to change before final release of log4j 1.3, so it may be better to avoid subclassing it since it really doesn't appear to be designed for extension and not that hard to duplicate. I think it should have been marked final, but then I think that about a lot of things.



It works because its format complies with the dtd (contained in the
log4.jar in org\apache\log4j\xml\log4j.dtd) and therefore I can validate it
and transform it into any format I like.

Exactly. Filter it, select just certain entries. Its the (slower) version of reading text output from log4j.

Is there a way I can .... (I'm looking for help here)
  Ask log4j to keep all the stuff I can set via the text properties
file, and then make it available via the api for the xml formatter?

What is "all the stuff I can set via the text properties"? Anything you can place in the MDC, NDC or properties should be present in the generated XML. If you want to discuss a configurable template, then I'd start looking at adding a new layout that drives an available XSLT implementation.





(And the next request will be... Can I ask some module who knows, to output <log4j:log> before my application starts writing and

   </log4j:log>
just before finishing :-)


A log file can be appended to by several invocations of an application each of which appends to the running log. If each invocation wrote <log4j:log> and </log4j:log> at its start up and termination, you would still have the problem of multiple document elements.


A possible solution is to use a o.a.l.rolling.RollingFileAppender with a RollingPolicy that instead of just renaming the file on a roll, it would add the outer document element.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to