commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Identify Class Loader Problems
Date Mon, 07 Feb 2005 18:27:31 GMT
Oh for better diagramming facilities in mail :-)

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

Ceki Gülcü <ceki@qos.ch> wrote on 02/07/2005 11:17:36 AM:

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


   System ClassLoader
            |
 +----------+---------+
 |                    |
Host --- creates --> Sub


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message