logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <...@qos.ch>
Subject Re: Recent commit by Paul
Date Mon, 04 Jun 2001 22:57:33 GMT

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ü <cgu@qos.ch> on 06/04/2001 02:16:39 PM
>
>Please respond to "LOG4J Developers Mailing List"
>      <log4j-dev@jakarta.apache.org>
>
>To:   "LOG4J Developers Mailing List" <log4j-dev@jakarta.apache.org>
>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: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>r
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

--
Ceki Gülcü


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


Mime
View raw message