commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] JCL2.0 design - Architecture
Date Mon, 27 Feb 2006 21:01:19 GMT
On Sun, 2006-02-26 at 17:26 +1300, Simon Kitching wrote:
> On Sat, 2006-02-25 at 17:56 +0000, robert burrell donkin wrote:
> > it should be much more reliable to allow per TCCL configuration whilst
> > loading implementations from the class classloader. IMHO we've encourage
> > too much use of automagic configuration. suggesting that users use
> > various arrangements of jars to achieve configurations has proved a poor
> > plan. limited automagic configuration to just the class classloader
> > would be a major simplification. 
> 
> I don't see how that could work.
> 
> If the underlying log implementation uses the TCCL to locate config
> info, then things are fairly simple; the user just disables TCCL
> functionality for JCL and lets the underlying logging system do its
> thing.
> 
> But if the underlying log implementation is not TCCL-aware, and uses the
> ClassLoader which loaded the logging library to locate its config info,
> then JCL *must* load that implementation via the TCCL in order to get
> the desired behaviour when JCL is deployed in a "shared" location.
> 
> And if we want to allow a webapp to redirect logging from classes it
> calls which are in a "shared" classpath into a logging lib that is *not*
> in the classpath (eg when webapp deploys log4j, container has something
> else) then again the TCCL must be used.
> 
> I do agree that "magic" configuration wasn't a good idea in hindsight.
> Perhaps a commons-logging.properties file should be mandatory?

i was thinking along the lines of mandatory for actively choosing a
logging system. JCL could still make a reasonable guess but using a
properties file would become the primary recommended mechanism for
configuration. 
 
> > i've also been toying with the idea of a Log implementation that
> > discovers which implementation to use based on the calling TCCL. when
> > debug is called, the Log implementation would be looked up. this would
> > allow a library to share a static implementation. of course the
> > configuration for each TCCL would have to be stored centrally.
> 
> You mean this?
>   public boolean isDebugEnabled() {
>     // get tccl
>     // build a (tccl, categoryname) pair
>     // do a hashmap lookup using the above pair to get the real Logger
>     // return realLogger.isDebugEnabled()
>   }
> That will work under all circumstances, but the crippled performance
> would seem to make this an unworkable solution IMO.

i've been wondering about how big the performance impact would actually
be. it's a way of achieving true isolation for those that really need it
at a price. might encourage users to think about the trade-offs involved
a bit more than they do now. 

- robert


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


Mime
View raw message