aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Wed, 09 Jun 2010 07:18:31 GMT

One of the ideas behind SPI-Fly is that it could work with SPI
providers that are not OSGi-aware but are bundelized. What I really
would like is not to have to modify any code in the SPI. However
adding an OSGi Manifest would be part of the bundelization effort
(that's where the opt-in header would come in). I believe that the SMX
SPI implementations actually have some additional code in the bundle,
some of which shadows code in the SPI jar itself (please correct me if
I'm wrong). Not too sure about the Geronimo solution does it also add
new code to the SPI bundle?

There are a couple of things that spring to mind.
* Maybe we can enhance the opt-in header with some instructions for
non-standard SPI implementations. Besides the ones mentioned in this
thread there are also examples where not the standard
META-INF/services/ location is used to list the service
implementations. (e.g. JavaMail seems to use
* Another idea is to allow special handlers to be registered with
SPI-Fly that know about certain specific SPI anomalies. I guess we
need to figure out how many anomalies there are to decide if this
makes sense, if the anomalies are confined to a small number of
technologies we might want to simply build support for those into

Best regards,


On 8 June 2010 20:48, David Jencks <> wrote:
> 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.
> thanks
> 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