ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: <script> needs a classpath param
Date Tue, 07 Aug 2001 00:38:23 GMT
> From: Sam Ruby []
> Paul Hammant wrote:
> >
> >> Do you know whether BSF supports context classloaders?
> >
> >Not sure ... Sam Ruby - do you know the answer to this?
> What's a "context" class loader?

In JDK 1.2+, each thread can have a class loader associated with it - the
context classloader. This is useful for JDK classes since it allows them to
create objects not available in the system classloader. For example the JNDI
Naming stuff. You typically pass this the classname for the factory object.
This class will usually not be available to the InitialContext class inthe
JDK. It can use the context classloader to try and create the factory

Context classloaders are a reaction or a consequence to the delegation model
class loading.

> BSF has no explicit support for class loaders,
> There's much I don't know about class loaders, but some of the statements
> made previously on this thread don't make sense to me.  My experience is
> that things loaded by a class loader do have access to objects created
> under other class loaders.

It depends :-)

> In fact, if the class loader delegates to its
> parent class loader, then classes loaded by that class loader can even
> create objects that can be returned to the caller.

The main problem is that once you "enter" the parent classloader, you can't
come back out. Classes loaded by the parent loader will not be able to see
classes available in the child loader. This is usually a problem for factory
style operations.

> My only comment on the requirement for a <classpath> is that such support
> should respect the value of build.sysclasspath, enabling me to turn off
> this support. ;-)



View raw message