Re: Adding Hashtable to LoggingEvent [WAS: Recent commit by Paul]

[Anders Kristensen <ak...@dynamicsoft.com>]

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: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org