commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [discovery] Use of ClassLoader in ClassFinder
Date Wed, 26 Jun 2002 19:48:39 GMT
On Wed, 26 Jun 2002 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 

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 )

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

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 unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message