RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

Alan Bateman Alan.Bateman at oracle.com
Thu Jun 21 18:04:46 UTC 2012


On 21/06/2012 18:34, Joe Wang wrote:
>
> :
>>
>> When iterating over the service instances you are catching 
>> ConfigurationError
>>
>>   264         ServiceLoader loader = ServiceLoader.load(serviceClass, 
>> cl);
>>   265         final Iterator providers = loader.iterator();
>>   266         while (providers.hasNext()) {
>>   267             try {
>>   268                 Object provider = providers.next();
>>   269                 if 
>> (provider.getClass().getName().contains(fallbackClassName)) {
>>   270                     defaultProvider = provider;
>>   271                 } else {
>>   272                     return provider;
>>   273                 }
>>   274             } catch (ConfigurationError e) {
>>   275                 // This can happen because of class loader 
>> mismatch or any other reason.
>>   276                 // log and continue to next one
>>   277                 if (debug) {
>>   278                     dPrint("The provider can not be 
>> instantiated due to: " + e + ".");
>>   279                 }
>>   280             }
>>   281         }
>> Did you mean ServiceConfigurationError?
>
> ConfigurationError is internally defined. It's a contract between the 
> Factory and FactoryFinder classes.  It seems to me it was a result of 
> sharing the FactoryFinders and different exception types defined in 
> the spec for different factories.
With ServicLoader then ServiceConfigurationError is thrown if there is a 
problem reading the service configuration file or the concrete type is 
not a sub-type or it cannot be instantiated.

With JAXP then I think most of the places it is specified to throw a 
JAXP <something>ConfigurationException when the provider cannot be 
instantiated (it seems to be silent as to issues encountered reading the 
service configuration file).

Minimally the above code will need to be changed to catch 
ServiceConfigurationError. Whether it ignores it and attempts to 
continue, or throws a JAXP ConfigurationError needs needs consideration. 
The existing behavior seems to be to ignore IOExceptions if there is a 
problem reading the service configuration file but I don't think it can 
distinguish this case when it gets a SCE. Therefore the safest thing may 
be to just throw ConfiguarationError and the callers of the factory 
finder call will translate it into the appropriate (and specified) JAXP 
*ConfigurationException.

-Alan.






More information about the core-libs-dev mailing list