For example,
<log4j:event logger="org.xyz.SomeLogger" timestamp="213341234" level="INFO" thread="main"> <log4j:message><![CDATA[some message]]></log4j:message> <log4j:propertySet> <log4j:property name="key1" value="val1"/> <log4j:property name="key2" value="val2"/> </log4j:propertySet> <log4j:mdc> <log4j:dc name="key1" value="val1"/> <log4j:dc name="key2" value="val2"/> ... </log4j:mdc> </log4j:event>
At 03:21 PM 3/19/2003 +0000, you wrote:
Couple of questions.
How will the logging event properties be represented in the event XML?
Good question. How about the following,
<log4j:event logger="org.xyz.SomeLogger" timestamp="213341234" level="INFO" thread="main"> <log4j:message><![CDATA[some message]]></log4j:message> <log4j:propertySet> <log4j:property name="key1" value="val1"/> <log4j:property name="key2" value="val2"/> </log4j:propertySet> <log4j:mdc> <log4j:dc name="key1" value="val1"/> <log4j:dc name="key2" value="val2"/> ... </log4j:mdc> </log4j:event>
Why is the <message> value a text node and the mdc key value an attribute node? Both are strings. Both could potentially contain characters that are invalid (or at least need escaping). If they are stored in different node types then they will need to be escaped differently. i.e. the <message> uses a CDATA section and the value attribute must use character references to encode invalid characters.
Another good question.
The message can be potentially very large. The message itself can be XML content in which case embedded CDATA sections must be escaped. Although theoretically possible, I don't think the MDC entries or properties to contain XML contain or be very long. Instead of CDATA section for property key ans values we have the option of safely transforming special characters to their XML entity equivalents. For example, '<' can be transformed to '<'. As you know, XMLLayout already does such transformations. If in 99.9% of cases there are no special chars, then the Transform.escapeTags will result in more compact output. If the content often contains XML or special chars, then Transform.appendEscapingCDATA is more appropriate. The Transform class is in o.a.l.helpers package.
The Transform.escapeTags methods could be optimized for memory consumption in case there are no characters to escape. It suffices to return the input string as is. I'll correct this shortly.
Thanks, Nicko
> -----Original Message----- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED] > Sent: 19 March 2003 14:45 > To: Log4J Developers List > Subject: Re: Adding more MDC support to several classes > > > > Paul, > > I suggest the following format: > > <log4j:event logger="org.xyz.SomeLogger" > timestamp="213341234" level="INFO" > thread="main"> > <log4j:message><![CDATA[some message]]></log4j:message> > <log4j:mdc> > <log4j:context name="key1" value="val1"/> > <log4j:context name="key2" value="val2"/> > ... > </log4j:mdc> > </log4j:event> > > Note that the MDC is optional. So the DTD should allow for > the possibility > of no MDC. > > > At 10:14 PM 3/19/2003 +1100, you wrote: > >Just following up on something Mark has mentioned offline re: adding > >some more support for MDC through XMLLayout, and Chainsaw. > I wanted to > >run some things by the group. Sorry if this is a bit long. > > > >The first thing that needs to happen is to modify the > log4j.dtd file to > >incorporate the MDC structure info. I'm no XML expert, but here's my > >first guess at an example format : > > > ><log4j:MDC> > > <MDC key="MyKey1" value="MyValue2"/> > > <MDC key="MyKey2" value="MyValue2"/> > > ....... > ></log4j:MDC> > > > >If anyone has any comments, speak up now! :) > > > >After we're set on the format, it'll be (as Mark said) a > snap to modify > >XMLLayout to include MDC, and then I think just a fraction > more effort > >to modify Chainsaw's XMLFileHandler to digest(!) the MDC > info back from > >XML into something Chainsaw handles. > > > >Lastly, the PatternParser class needs to provide a format > for outputing > >ALL the MDC key/value pairs if no extra %X option is added. > Now, since > >the MDC is basically a Hashtable, would anyone object to the > format of > >the output via the PatternParser being just the > Hashtable.toString()?. > >cheers, > > > >Paul Smith > > -- > Ceki > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]