aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bartosz Kowalewski <>
Subject SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Tue, 08 Jun 2010 19:23:33 GMT
Hi all,

I took a quick look at SPI-Fly, did some simple experiments and read
this short guide:
I think that the issue with javamail that Guillaume mentioned there is
not the only one that would probably need to be fixed. Javamail breaks
the Jar file spec by using constructors that have arguments. The
problem that I observed is a bit different. I think that the JAXB
library does not break the SPI section of the Jar spec, but still
cannot be properly processed by SPI-Fly. The spec suggests that the
fully qualified class name should be used for the
provider-configuration file name. However, I think that it's only a
recommendation. The current version of SPI-Fly treats this as a
requirement and not a recommendation. While SPI-Fly itself does not
check if this condition is met, it uses the  provider-configuration
file name when registering the service. OSGi service registry will
throw an exception as such a registration is not allowed.

For JAXB the service provider file name is:
Service implementation for this name does not need to extend any
abstract class or implement any interfaces. It only needs to have a
method named createContext. This might be a violation of the Jar spec.

The problem of different interpretations of the Jar spec use in
various APIs has been solved in ServiceMix. Each SMX bundle with 'an
enhanced' spec has its own extender and uses the classname retrieved
using SPI in its own specific way. In SPI-Fly there's a single
extender and all detected service providers are registered in the
service registry. This makes handling all those weird variations of
SPI used in JRE really difficult.

Best regards,

View raw message