aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bartosz Kowalewski <kowalewski.bart...@gmail.com>
Subject Re: SPI-Fly and provider-configuration file names that are different than the abstract service class
Date Wed, 09 Jun 2010 20:52:48 GMT
Hi,

I'm not sure how Geronimo works around the restrictions that OSGi puts
on SPI. ServiceMix does not change the contents of the jars/bundles
that define providers/API implementation. However, each bundle that
provides specific API itself is slightly modified. It contains two
extra classes - always the same two classes. They transform each such
API bundle into an OSGI extender. Of course some modifications were
also applied to already existing classes (the ones that used to load
definitions from META-INF/...). Instead of loading definitions from
META-INF/..., they use the extender.

While building support for specific anomalies into SPI-Fly would
eliminate the problems with processing provider bundles and
registering SPI related services in the OSGi service registry, it
would not modify the way in which API bundles detect these providers.
It might have missed something, but I think that SPI-Fly currently
addresses only a half of the SPI invocation. You can get SPI providers
from the OSGi registry, but you cannot use an API that is based on
these providers. Unfortunately, making API bundles use the OSGi
services that SPI-Fly registers instead of the standard approach
(classloader.getResourceAsStream("/META-INF...")) would require a
modification in each API bundle. I guess that making those APIs work
properly in an OSGi environment is not in scope of the SPI-Fly
project. Am I right?

Best regards,
  Bartek

2010/6/9 David Bosschaert <david.bosschaert@gmail.com>:
> Hi,
>
> 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
> META-INF/javamail.default.providers).
> * 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
> SPI-Fly...
>
> Best regards,
>
> David
>
> On 8 June 2010 20:48, David Jencks <david_jencks@yahoo.com> 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: http://incubator.apache.org/aries/spi-fly.html
>>> 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
>>
>>
>

Mime
View raw message