Classloader isolation and Manifest Class-Path headers

Discussion in 'Java' started by ljnelson, Mar 31, 2006.

  1. ljnelson

    ljnelson Guest

    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

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

    ljnelson, Mar 31, 2006
    1. Advertisements

  2. ljnelson

    ljnelson Guest

    ljnelson, Mar 31, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.