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 )
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 ).
Costin
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
|