> 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>
I don't see why the <log4j:property name="key1" value="val1"/> and <log4j:dc name="key1" value="val1"/> Need to be different.
Essentially you just have a 'generic' map. They have different names, one is propertySet (not really a set by the way, definitely a map) and mdc (also a map). Why can't they have the same xml data items:
<log4j:data name="key1" value="val1"/>
True enough. I don't see it matter much either way. Do you?
> >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.
You don't need to use a CDATA section for the message, you could use Transform.escapeTags for the message itself. In fact the best idea would be to use a version of Transform.escapeTags that tried to escape tags, but if there were too many escapes (i.e. more than 4 escapes) it aborts escaping and wraps the text in a CDATA section.
That's an original idea. Do you have an implementation in mind?
Again I prefer the consistency of using a single representation for data values. The real benefit of attribute values is that you can easily select on their value using things like XPath. While you are likely to do this for things like Level, your are unlikely to do this for mdc values.
Given the following:
<log4j:dc name="key1" value="val1"/> <log4j:dc name="key1">val1</dc>
<log4j:property name="key2" value="val2"/> <log4j:property name="key2">val2</property>
<log4j:d n="key2" v="val2"/> <log4j:d n="key2">val2</d>
It's obvious that the most efficient representation depends on the names chosen for the element and attribute names.
Another point I would like to bring up is that currently the NDC is encoded in the same way as the message, i.e. as a data blob. The NDC is a stack of data, the stack information is lost in the xml version. This could better be encoded as:
<properties context='ndc'> <item>[item value]</item> <item>[item value]</item> <item>[item value]</item> </properties>
Or:
<ndc> <item>[item value]</item> <item>[item value]</item> <item>[item value]</item> </ndc>
Or:
<ndc> <item value="[item value]"> <item value="[item value]"> <item value="[item value]"> </ndc>
Once the NDC is output it no longer makes much sense to manipulate it whereas it might make sense to *selectively* list items from the MDC by key. Note that there is no way to access the i th element on the NDC stack. No one has ever asked for it either. If however there was a NDC.get(int) method, then my previous statement becomes much less grounded in reality.
Just more thoughts... Thanks for listening
Nicko
--
Ceki
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
