Hello Paul,
Complexity is not the right word. The right term would be lack of reliability. The
user can get a category of a different type than expected depending on the order of
initialization of things. It's not a problem with your extensions. Anyway, I have to
get some sleep now. Tomorrow is another day.. Ceki
At 15:06 04.06.2001 -0700, you wrote:
>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]
>
>
>r
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
