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.
