That's actually what I've done with the slight modification of
SocketAppender called SocketTextAppender.
The event is converted to XML in the log4j.properties file. ie.:
log4j.appender.A3.layout.ConversionPattern=<LOG><DATE>%d</DATE><SEVERITY
>%p</SEVERITY><CLASS>%c</CLASS><THREAD>%t</THREAD><MESSAGE>%m</MESSAGE><
/LOG>%n
-----Original Message-----
From: Anders Kristensen [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 5:29 PM
To: LOG4J Developers Mailing List
Subject: Re: Adding Hashtable to LoggingEvent [WAS: Recent commit by
Paul]
IMHO, we should not add a Hashtable to LoggingEvent to address
brittleness of serialized LoggingEvents and probably not for any other
reason either.
If a particular Appender (a derivative of SocketAppender perhaps) wants
to serialize LoggingEvents as a set of string name-value pairs or XML
encoded content, then fine -- it can go and do that. There's no need to
modify LoggingEvent for this purpose.
I think we should have very good reasons for adding overhead (CPU,
memory, or conceptual complexity) to the log4j core. So far I haven't
heard any convincing reason for adding Hashtable to LoggingEvent.
Just my $0.02.
Cheers,
Anders
Ceki Gülcü wrote:
>
> At 10:43 04.06.2001 -0700, you wrote:
> >Ceki,
> >
> >The PropertyConfigurator only sets the default category factory when
> >someone has specified that a different category factory be used (via
the
> >categoryFactory property). Without this behaviour, we are saying go
ahead
> >and specify any factory you want, but you can't use it to instantiate
> >categories in your code.
> >
> >Perhaps, as you alluded to, we could make this configurable -
something
> >like
> >
> > log4j.defaultFactoryOverride=true
> >
> >would allow a configurator to modify the hierarchy's factory.
>
> Hi Paul,
>
> Yes, that is certainly better.
>
> However, I am still not satisfied with the current solution (or lack
thereof) to the extension problem mainly due to its complexity. I think
a new approach is in order.
>
> Here is what I have in mind:
>
> 1) Add a HashTable field to LoggingEvent.
>
> 2) Let Appenders populate this HashTable with appropriate keys and
values.
>
> 3) Allow the serialization of this Hashtable field and its contents
along with the rest of the LoggingEvent.
>
> 4) Let servers print the values in the Hashtable as they see fit.
>
> Comments? 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
