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 Wed, 26 Jun 2002 23:58:34 GMT
On Wed, 26 Jun 2002, Craig R. McClanahan wrote:

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

Throwable.getStackTrace() is 1.4 specific.

SecurityManager.getClassContext() is there from 1.1. I never used
it ( except in sandbox mode), but it does the same thing
( without the method names and line numbers - we only need the classes).
 

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

Yes.


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

Probably a static ( and guarded ) field is enough. I think the policy 
shouldn't be setable by user or SPI, but by container - for 
security reasons. 

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