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