Ceki,
Are you saying that the current manner of logging extensions (which, beyond
adding more appenders, usually amounts to the desire to add extra logging
attributes) is too complex? Perhaps I've been immersed in it for too long
to see it. From my prospective, the only undocumented complexity was that
of configuration. I was hoping to squash this using PropertySetter.
Adding a Hashtable to LoggingEvent and relying on an (extended) Appender to
populate it would certainly lighten the load on extending (and hence
configuring) Category. But then there would have to be a new Appender
extension for every type of desired target: an extended console appender,
socket appender, file appender etc.
I feel that the critical behavior to extend is the creation of the logging
event itself (i.e. the forcedLog method of Category). To extend this you
need to be able to extend category. To successfully extend Category, you
need to be able configure category extensions, which amounts to configuring
the extended factories and using them.
Perhaps a compromise can be reached whereby an extended category factory
constructor sets itself as the factory of choice on its associated factory
class. For example:
// inside of MyCategoryFactory ctor
//
// finish internal initialization
//
MyCategory.setFactory(this);
In fact, this should be done regardless of how we proceed with
PropertyConfigurator. Then the user can reach the standard category using
Category.getInstance
and reach the extended category using
MyCategory.getInstance
I'm still not sure what we gain by leaving Hierarchy's category factory
unmolested. What we lose is the ability plug and play Category extensions
by simply modifying a property file.
Paul Glezen
IT Specialist
Software Services
818 539 3321
Ceki Gülcü <[EMAIL PROTECTED]> on 06/04/2001 02:16:39 PM
Please respond to "LOG4J Developers Mailing List"
<[EMAIL PROTECTED]>
To: "LOG4J Developers Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: Re: Recent commit by Paul
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]
