Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <6.0.3.0.0.20050207180827.039ffd80@mail.qos.ch>
Date: Mon, 07 Feb 2005 18:17:36 +0100
To: commons-dev@jakarta.apache.org
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <ceki@qos.ch>
Subject: Re: [logging] Identify Class Loader Problems
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable


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.


--=20
Ceki G=FClc=FC

   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