Rob Walker wrote: > > > Are you saying that you tried your proposed solution on JDK 1.4 and got > > it to work? I don't know enough about your app to understand. I think > > we agree that the problem exists in JDK 1.4. In addition, I think that > > the proposed solution will probably still fail unless you are using JDK > > 1.4 in a non-standard way. > > The problem (and solution) are exactly the same under JDK1.3 and JDK1.4. > Due to the nature of OSGi, which uses modular classloaders, the Xerces.jar is > not on the classpath. It is loaded by a custom classloader. > > > > > I would expect that setting the context CL to your custom CL which has > > access to the impl classes will always work, however. Unfortunately, I > > have not heard of a better solution to this problem yet. > > This does always work - but it means every single thread that is created in > the > VM has to remember to set it's context classloader - which is a total pain. In > every case, the solution is "set context classloader from > this.class.classloader" - > which implies to me that Xerces could have this as a fallback option if a > class is > not found through the thread context classloader.
In JDK 1.4, the FactoryFinder (package private) class is part of rt.jar which means that if you use the usual class loading delegation model, it will be loaded by the bootstrap CL. Thus, the code FactoryFinder.class.getClassLoader() will return the bootstrap CL and not your custom CL that has access to the parser impl that you want to load. The result is that the class will still not be found. -Edwin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
