> 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"/>



> >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 '&lt;'. 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.

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>


Just more thoughts...
Thanks for listening

Nicko


> 
> >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]
> 

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

Reply via email to