aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Tue, 08 Jun 2010 19:48:09 GMT
There are problems with the servicemix attempt to osgi-ify j2ee specs too.  We think we've
solved all the problems and are loading classes and finding services in spec-compatible and
osgi-compatible ways in the latest geronimo specs and javamail implementation.  I think Rick
McGuire (who investigated this very thoroughly and came up with the geronimo solution) commented
on spi-fly as well.

david jencks

On Jun 8, 2010, at 12:23 PM, Bartosz Kowalewski wrote:

> 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:
> javax.xml.bind.JAXBContext
> 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,
>  Bartek

View raw message