commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: commons-logging auto-detection
Date Thu, 06 Jan 2005 21:46:51 GMT

On 4 Jan 2005, at 19:15, Paul Libbrecht wrote:

> Le 4 janv. 05, à 19:42, Richard Sitze a écrit :
>> I think that what you are asking for is a way to bind a LogFactory
>> instance to a particular ClassLoader, perhaps immediately following 
>> the
>> construction of the ClassLoader instance:
> Well, if I was in control of the application, that would be true but I 
> am not.
> (more or less).
> I still insist on something like a method static 
> LogFactory.getLogFactoryOfThread() which would use a previous call to 
> LogFactory.setLogFactoryOfThread(LogFactory).

i'd see that this kind of thing is exactly what an additional 
configuration layer could enable. i'd be very, very reluctant to see 
this added into JCL as it is at the present since it would added 
complexity which would only be useful for a limited set of 
environments. in others it may be positively harmful (for example, 
server environments where threads are pooled).

given the extra layer proposed, the discovery/configuration mechanism 
that should be employed for the JVM would be set by a system property. 
each pluggable implementation would be capable of supporting whatever 
extra configuration it needed. so, ThreadLogFactory (for example) might 
discovery the right implementation to use based on the value of a 
thread local variable and could support setters (as described above). 
when a brick was used by an application running in a suitable 
environment, the application would just need to ensure that the 
appropriate system property was set and then the LogFactory discovery 
would use the thread local mechanism.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message