commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [discovery] Use of ClassLoader in ClassFinder
Date Wed, 26 Jun 2002 20:43:04 GMT
In general, I agree with Costin's suggestions, but have a couple of
thoughts intermixed below.

On Wed, 26 Jun 2002 costinm@covalent.net wrote:

> Date: Wed, 26 Jun 2002 12:48:39 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: [discovery] Use of ClassLoader in ClassFinder
>
> On Wed, 26 Jun 2002 rsitze@us.ibm.com wrote:
>
> > Sorry... SPI == Service Provider Interface OR Service Programming
> > Interface.  It's not stricly a Java Interface; it can be an interface,
> > abstract class, or class.
> >
> > Example:   org.apache.commons.logging.LogFactory could be a service
> > provider interface.
>
> > Call ServiceFinder.find(org.apache.commons.logging.LogFactory, ....)  to
> > locate an implementation of that interface.
> >
> > So, as-per my earlier note, the ClassFinder uses the context class loader
> > and the class loader used to load LogFactory.
>
> I think this is a bit incorect. The interface is very likely to be in a
> parent loader ( for example commons-logging may be needed by the startup
> code and other components in parent ).
>
> I think we should try:
> 1. thread class loader - this will locate services in WEB-INF/lib for
> example
>
> 2. caller class loader ( i.e. up the stack, and find the class that
> called LogFactory.getLog() and use it's loader ). This will locate
> loggers in the same loader with the caller ( for example if an app
> creates it's own loader, which includes a particular logger )
>

Is this feasible in a pre-1.4 JVM?  I didn't think the necessary machinery
was available earlier, so maybe this will have to be 1.4 specific.

> 3. use the class loader used to load LogFactory or the discovery
> classes - this can locate 'default' impl., in the same loader as
> the discovery or LogFactory.
>
> 4. the system class loader

This is especially useful in container environments that don't necessarily
make application-specific classloaders children of the system class loader
(the way Tomcat currently does, for example).

>
> Each of those loaders can locate a valid implementation - but I'm
> not sure about the order.
>
> In some cases we may want to force the discovery of a certain
> implementation set by container, for example if tomcat runs the apps in
> a sandbox and wants to force a certain trusted logger, even if the app
> includes an implementation ( in this case the impl. in WEB-INF/lib
> may not have the permissions - it's safer to grand it to a trusted
> logger under control ).
>

To meet this need, we might want to make the discovery order configurable,
but then we're going to have the fun chicken-and-egg problem of how the
discovery algorithm discovers its own configuration settings ...

> Costin
>
>

Craig


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message