0

I'm writing a plugin for a framework that loads my code as a child classloader

The problem is that that framework uses a certain Xerces version, that is not compatible with my code, I want to use my "own" jar for xerces, but it seems since the old one was already loaded, I can't seem to make my code use mine.

I'm looking for some classloader seperation, I know it's a know problem, but can't seem to solve it

Is there any framework, library, or code sample to user locally a newer jar in such a scenario?

Eran Medan
  • 44,555
  • 61
  • 184
  • 276
  • See my related question http://stackoverflow.com/questions/5447633/how-to-prevent-xalan-jar-that-has-meta-inf-services-javax-xml-transform-transform – Eran Medan Mar 27 '11 at 06:36

2 Answers2

1

Have you tried loading the classes of your framework and Xerces libs as a part of the ExtClassLoader by placing them in path corresponding to the java.ext.dirs system property? This way the framework's version of Xerces implementation will be loaded by the ExtClassLoader.

You can then place your version of Xerces implementation in the path corresponding to the java.class.path system property to be loaded by the AppClassLoader.

I have not tried this myself, but considering the class loading hierarchy this should work. You can learn more about the class loading hierarchy here - http://onjava.com/pub/a/onjava/2005/01/26/classloading.html

shaktimaan
  • 11,962
  • 2
  • 29
  • 33
0

try doing:

ClassLoader oldContextClassLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(childClassLoader);
try{
    // do xml parsing
}finally{
    Thread.currentThread().setContextClassLoader(oldContextClassLoader);
}
Santhosh Kumar Tekuri
  • 3,012
  • 22
  • 22
  • Thanks, I assume childClassLoader can be achieved by doing this on a class loaded by it: getClass().getClassLoader(), right? will try and write back... – Eran Medan Mar 26 '11 at 13:44