JDK-7169894 : JAXP Plugability Layer: using service loader
  • Type: Enhancement
  • Component: xml
  • Sub-Component: jaxp
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2012-05-18
  • Updated: 2017-05-17
  • Resolved: 2013-01-09
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.
Related Reports
Cloners :  
Duplicate :  
Relates :  
Relates :  
JAXP defines a Plugability Layer that specifies how it will locate an implementation or service provider. In the Java API documentation, the Plugability Layer is described in all of the factories including 
javax.xml.datatype.DatatypeFactory, javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.SAXParserFactory, javax.xml.stream.XMLEventFactory, javax.xml.stream.XMLInputFactory, javax.xml.stream.XMLOutputFactory, javax.xml.transform.TransformerFactory, javax.xml.validation.SchemaFactory, and javax.xml.xpath.XPathFactory.

The process is best described in javax.xml.datatype.DatatypeFactory as follows.

Quote from the Java API Documentation of javax.xml.datatype.DatatypeFactory:

newInstance() is used to create a new DatatypeFactory. The following implementation resolution mechanisms are used in the following order:

1. If the system property specified by DATATYPEFACTORY_PROPERTY, "javax.xml.datatype.DatatypeFactory", exists, a class with the name of the property's value is instantiated. Any Exception thrown during the instantiation process is wrapped as a DatatypeConfigurationException. 

2. If the file ${JAVA_HOME}/lib/jaxp.properties exists, it is loaded in a Properties Object. The Properties Object is then queried for the property as documented in the prior step and processed as documented in the prior step. 

3. The services resolution mechanism is used, e.g. META-INF/services/java.xml.datatype.DatatypeFactory. Any Exception thrown during the instantiation process is wrapped as a DatatypeConfigurationException. 

4. The final mechanism is to attempt to instantiate the Class specified by DATATYPEFACTORY_IMPLEMENTATION_CLASS. Any Exception thrown during the instantiation process is wrapped as a DatatypeConfigurationException. 

In a module system, the location of a service provider will be centered around finding modules that provide the service. The process defined in the JAXP Plugability Layer will need to be modified accordingly. This change request is targeted to changing the 3rd step, the basis of the process. Other changes will be requested in the future as the general solutions in the areas of module finding and loading become clearer (for example, if there may be a preferred service, or if there's a way to pick a specific provider).

Below is the change for the 3rd step. 

In javax.xml.datatype.DatatypeFactory, the description of the process is in the beginning of the class, while for all other factories, it is in the newInstance method. The descriptions were slightly different among different factories. With this change, all of them will use the same text as follows.

3. Using the service-provider loading facility defined by the java.util.ServiceLoader class to attempt to locate and load an implementation of the service. Any Exception thrown during the instantiation process is wrapped as a ConfigurationException.

duplicate with JDK-8005954

This request is now tracked by JDK-8005954

Partial patch for changes in the javax.xml.parsers package. Reviewed by Alan Bateman, Mandy Chung, and Joe Wang. http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.04/ This here addresses changes in the javax.xml.parsers package for the SAXParserFactory and DocumentBuilderFactory - and more specifically their no-argument newInstance() method. This change replaces the custom code that was reading the META-INF/services/ resources by a simple call to ServiceLoader. Behavior/Spec changes ================== Due to the use of ServiceLoader exception chaining is slightly changed. Before: In some cases the factory used to throw an exception - wrapped or not in FactoryConfigurationError (the cases where the exception was not wrapped could have been construed as bugs). After: Now the factory might throw a FactoryConfigurationError wrapping a RuntimeException wrapping a ServiceConfigurationError possibly wrapping the previous exception. This is because the new factory now calls the ServiceLoader, and wraps its ServiceConfigurationError in a RuntimeException in order to wrap it again in FactoryConfigurationError. This might look a bit complex but FactoryConfigurationError was not designed to wrap any Error - only Exception - and changing FactoryConfigurationError might have introduced bigger compatibility issue anyway. So the exception chaining will change in some cases - but since only FactoryConfigurationError was documented in the previous version of the spec - and since it only concerns cases of misconfiguration, it should hopefully not cause any compatibility issue.

EVALUATION Starts initial review: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/.