JDK-6975142 : JAXP FactoryFinder fails to locate provider
  • Type: Bug
  • Component: xml
  • Sub-Component: javax.xml.stream
  • Affected Version: v3.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2010-08-06
  • Updated: 2014-02-11
  • Resolved: 2014-02-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.0Resolved
Related Reports
Relates :  
JDK-7169894 - JAXP Plugability Layer: using service loader
Relates :  
JDK-8005954 - JAXP Plugability Layer should use java.util.ServiceLoader
Description
[Filing on bahalf of ###@###.###, as he does not have bugster write access]

JAXP FactoryFinder in JRE makes incorrect assumption about class loaders and throws ClassCastException in OSGi environment. See https://glassfish.dev.java.net/issues/show_bug.cgi?id=11860 for details. 

JRE has javax.xml.stream.XMLInputFactory.class and a default implementation of this service class. Woodstox bundle has javax.xml.stream.XMLInputFactory.class and a default implementation. For whatever reason, woodstox does not use javax.xml.stream.XMLInputFactory.class from JRE, instead, it loads from its own bundle (Please note, boot delegation is not the default in OSGi environment).

User is using XMLInputFactory from JRE. Now, XMLInputFactory.newFactory (or an equivalent method) is called by user. For whatever reason, if it finds META-INF/service file in woodstox bundle, it will try to instantiate the woodstox provider and return it, but since woodstox uses its own StAX APIs, it results in a ClassCastException.
Comments
EVALUATION As discussed with Sahoo, the service mechanism can't discover providers bundled inside OSGi bundles. A special class loader can be designed to load Woodstox provider. However, the Woodstox provider seems to be not compatible with the JDK, resulting in a ClassCastException when JDK StAX API is imported. We need to fall back to JDK's default StAX provider.
13-08-2010
SUGGESTED FIX PFA a patch that was generated against FactoryFinder.java that's distributed along with JDK 6u16. The patch works like this: It uses java.util.ServiceLoader to locate service providers. While iterating over candidate providers, it does not assume that every provider returned is class loader compatible with the service class. So, it catches the ServiceConfigurationError which can be thrown by iterator.next() when the provider can't be cast to the service class. See the glassfish issue for a description when this can happen. The important code in the version of FactoryFinder attached here with is shown below: ServiceLoader loader = ServiceLoader.load(serviceClass, cl); final Iterator providers = loader.iterator(); while (providers.hasNext()) { try { return providers.next(); } catch (ServiceConfigurationError e) { // This can happen because of class loader mismatch or any other reason. // log and continue to next one if (debug) { dPrint("This provider is not suitable because of: " + e + ". Will try next one."); } } }
06-08-2010