commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [discovery] Use of ClassLoader in ClassFinder
Date Thu, 27 Jun 2002 00:02:50 GMT
On Wed, 26 Jun 2002 rsitze@us.ibm.com wrote:

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

I think log4j has a nice mechanism for that - just have the SPI
pass itself as param to ServiceFinder, then service finder will
walk one level up. 

I agree this is tricky - but in some cases it may help, and if we're
going to use a 'common' discovery mechanism, then we can make it 
a bit more sophisticated and complete.


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

Not allways. You can do new URLClassLoader() with null as parent - i.e
start from top, a new hierarchy. Tomcat does it.

Costin


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