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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
