Classloader isolation and Manifest Class-Path headers

[ljnelson]

I have hit a brick wall here.

I have a system that loads modules. Each module is represented by a
jar file. Each jar file is loaded by its own URLClassLoader whose
classpath is simply that jar file and nothing else.

Now, each jar file may "widen" its own classpath by specifying things
in its Class-path header in its manifest, in accordance with the jar
specification.

What I'm finding is that classes that are loaded by way of this
extension mechanism--and, although I haven't tested it, I suspect all
classes, actually--"leak" over to another module's loader, rather than
being loaded by *that* module's loader. An example should help.

Consider three jars, A, B and C. A is loaded by loaderA, B is loaded
by loaderB, and C appears in the Class-path header of A and B. C, in
turn, contains Foo.class, which is needed by A and B.

If A is loaded first, then Foo.class is loaded by loaderA, and when B
goes to look at it, it sees that Foo's classloader is loaderA instead
of loaderB. I don't want this; I want two potentially separate
instances of Foo loaded.

How can I accomplish this? Must I override the findLoadedClass()
method in URLClassLoader to keep track of the classes I've actually
loaded (instead of dropping down to the private native
findLoadedClass0() method in java.lang.Classloader)?

Thanks,
Laird

 

[ljnelson]

The issue turned out to be much more esoteric than this would lead you
to believe. I have a writeup available at
http://jroller.com/page/ljn?entry=bsfmanager_hijinks for those who are
interested.

Thanks,
Laird