I've had the same problem last year. I was able to work around it by
removing the context class loader that was active:
private XPathFactory createXPathFactory() {
Thread t = Thread.currentThread();
ClassLoader cl = t.getContextClassLoader();
t.setContextClassLoader(getClass().getClassLoader());
try {
return XPathFactory.newInstance();
} finally {
t.setContextClassLoader(cl);
}
}
Please note that I have my own versions of the JAXP API (1.4.01), Xerces,
Xalan and Serializer in the bootclasspath, since the JRE's usually ship
with buggy Xerces/Xalan forks.
HTH
Jeremias Maerki
On 11.07.2012 18:59:19 Dan Gravell wrote:
> Long story short: I just used org.osgi.framework.bootdelegation.
>
> I tried using the XPath API for specifying the classloader. My initial
> attempt was this:
>
> XPathFactory xpathFactory =
> XPathFactory.newInstance(XPathFactory.DEFAULT_OBJECT_MODEL_URI,
> "com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl",
> XPathFactory.class.getClassLoader());
>
> Which is horrible because I have to specify the impl as I said in my
> previous email.
>
> Anyway, this didn't work because XPathFactory.class.getClassLoader()
> resolves to null, I guess because XPathFactory is loaded by the boot
> classpath class loader. I'm not sure on the best way to get the boot
> classpath class loader in an OSGi environment.
>
> Because the class loader is null, XPathFactory falls back to using the
> context class loader again.
>
> I decided that the improvement gleaned from using the specific ClassLoader
> API was reduced significantly by having to specify the XPathFactoryImpl
> name anyway, and so I am just going to use bootdelegation.
>
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
