commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [logging] Identify Class Loader Problems
Date Mon, 07 Feb 2005 17:17:36 GMT

On 2005-01-27 22:52:02, Richard Sitze wrote:

Richard,

Sorry for not responding earlier. I'be got a question regarding item C.

 > C.  Host / Sub
 >
 >   - commons-logging.jar#org.apache.commons.logging.Log is
 >     loaded/loadable by Host.
 >
 >   - A host, such as JUnit, creates and manages an independent Sub
 >     ClassLoader
 >
 >   - Sub does NOT reference Host as a parent.

How is that possible? As far as I know, a child class loader will
(by default) inherit the system class loader as a parent, in this case
'Host'.

As the set up you describe seems impossible to me, I can't make sense
of the rest of your conclusions for item 'C'. What am I missing?

 >   - Sub is set as the thread context ClassLoader.
 >
 >   - Execution is within code belonging to Host.
 >
 >   Problems:
 >
 >   1. The discovery process may *fail* altogether as it starts with the
 >      thread context class loader, and cannot reach the Host loader.
 >
 >   2. The discovery process allows a Log implementation defined by the
 >      Sub to be discovered by the Host, as the host executes
 >      Host[LogFactory], via the thread context class loader.
 >      Consider the case where the *Sub* defines
 >      commons-logging.properties
 >      or META-INF/Services/org.apache.commons.logging.Log.




-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



---------------------------------------------------------------------
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