There seems to be more to the code than that. After working out the classloader it then creates an "XPathFactoryFinder" and calls "newFactory()" on it. The real logic (if you can call it logic...) seems to happen in "XPathFactoryFinder._newFactory(String)" which does all kinds of stuff like looking for system properties, trying to find a file calles jaxp.properties in the Java installation directory, and so on. It's probably not worth trying to work out in advance how that code works, I would just debug it.
Note that I've run into bugs in this area in the OpenJDK where it actually differed in functionality from the Sun/Oracle JDK. In that case it was the XMLInputFactory class from StAX, but the factory loading code looked very similar to this. Even though I provided it with the correct classloader, it didn't actually *use* the classloader I provided. Like I said... batshit crazy stuff in the JRE! (sigh) On Wed, Jul 11, 2012 at 12:49 PM, Dan Gravell <[email protected]> wrote: > Looking at the OpenJDK (I'm not sure on whether impls are shared by > different JREs... anyway...) it appears to prefer the thread context > classloader, if it is not null. Otherwise. it uses the XPathFactory class's > classloader (which should work, but I suspect the context class loader is > non-null). > > To be fair, I missed before that there is a way of doing this by specifying > the class loader. I assume setting this to the XPathFactory's class's class > loader is correct, rather than my bundle class's classloader. > > For boot delegation, "com.sun.*" can be used rather than all package names > right? I have no idea what classes might be loaded in the depths of the 3rd > party libraries I use. This could blow up at any time. > > Dan > > On Wed, Jul 11, 2012 at 12:34 PM, Neil Bartlett <[email protected]>wrote: > >> Well... it depends what the XPathFactory.newInstance() method actually >> does in order to load the class. For example it may try to walk up the >> stack and load from the calling classloader. This is the JRE we're >> talking about, so you have to expect it to be batshit crazy and as >> complicated as possible! >> >> I think in this scenario you should probably add the package >> "com.sun.org.apache.xpath.internal.jaxp" to bootdelegation, since it >> isn't a real dependency of your bundle, and the JRE is assuming that >> it's always visible. I'd like to hear the opinion of others on this >> though. >> >> Neil >> >> On Wed, Jul 11, 2012 at 12:29 PM, Dan Gravell >> <[email protected]> wrote: >> > I'm a little puzzled about this. I have the following piece of code: >> > >> > XPathFactory xpathFactory = XPathFactory.newInstance(); >> > >> > I have the following import in the manifest for the bundle containing the >> > above code: >> > >> > Import-Package: javax.xml.xpath >> > >> > When I run, I get: >> > >> > java.lang.RuntimeException: XPathFactory#newInstance() failed to create >> an >> > XPathFactory for the default object model: >> > http://java.sun.com/jaxp/xpath/dom with the >> > XPathFactoryConfigurationException: >> > javax.xml.xpath.XPathFactoryConfigurationException: No XPathFactory >> > implementation found for the object model: >> > http://java.sun.com/jaxp/xpath/dom >> > at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:98) >> > >> > It looks like XPath tries to load the class >> > "com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl". >> > >> > Shouldn't this work? I only need to import the package for the API I use, >> > not the impl too right? >> > >> > Do I need to add com.sun.org.apache.xpath.internal.jaxp to the >> > Export-Packages on my system bundle fragment? If so, why? I thought this >> > was only required if I was directly >> > accessing com.sun.org.apache.xpath.internal.jaxp (with a requisite >> > Import-Package) from my bundle. >> > >> > Dan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
