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 20:38:35 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
>> 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

This is as it is today.

>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 )

This could get ugly.  If I call LogFactory.getFactory() or LogFactory.
getInstance(), then the discovery code needs to backup past it's caller
(LogFactory, 1 or 2 methods depending.

If I call ServiceFinder.find directly, then the discovery code needs to
backup to it's immediate caller.

Granted, the ServiceFinder COULD eliminate the SPI as a candidate for the
caller, but that assumes that a wrapper of ServiceFinder IS the SPI, and
I'd prefer not to go that direction.

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

This is the second class loader (spi's classloader: spi is LogFactory in
this case).

>4. the system class loader

Hmm... isn't this generally 'up-the-chain' from the lower-level
classloaders?  Checking this 'first' makes sense in some situations (not
this one).

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message