RE: Writing log in xml format

[Curt Arnold]

I sorry I really can't follow this thread.  There seem to be a couple  
possible issues that are trying to be raised, but I can't be sure.

1. You don't like using < or > in an XML configuration file to  
specify a '<' or '>' character.

Using a PatternLayout to fabricate XML elements is not robust since it  
will not properly escape messages that contain markup characters.  If  
you know that your messages never contain markup characters and are  
willing to accept the consequences, it should work but you would need  
to escape the markup in the XML configuration file like:

    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern"  
value="&lt;e&gt;&lt;t&gt;&lt%d{yyyy-MMM-dd
HH:mm}&lt;/t&gt;&ltlvl&gt;%-5p&lt;/lv&gt;&lt;m&gt;%m&lt;/m&gt;&lt/ 
e&gt;%n"/>
    </layout>	

Obviously, your configuration would be prettier if the configuration  
file processor magically knew when you wanted < to be a literal and  
when you wanted it to be part of an tag.  However, adding complexity  
and context-specific behavior to make the document prettier goes  
against the XML ethos.  < marks the start of a tag, &lt; is the '<'  
character and we need to stick with that.

2.  You'd like to be able to control the namespace, element names, etc  
in an XML log

If you are browsing the generated logs using a browser, you could use  
an XSLT style declaration and many browsers would apply the stylesheet  
and display the transformed log.

If you can't apply XSLT processing to the currently generated XML  
format, it could be possible to enhance the XMLLayout (or provide an  
alternative layout) to provide some facility for controlling the  
generated output.  I have some ideas but I don't want to go down that  
path if that isn't your concern.

3. The existing XMLLayout fails for particular message content and you  
are trying to find a work-around

Please clarify what your issues.  Using PatternLayout to fabricate XML  
messages will never be robust so do not expect us to make any  
improvements to make it better at something that it will eventually  
fail at.  If there flaws in XMLLayout or unsupported use-cases please  
describe them and we can consider enhancements or alternatives to  
XMLLayout.

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