geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Geronimo specs jars in OSGi
Date Thu, 17 Apr 2008 14:40:59 GMT
IIUC, they're not entirely legacy, i.e. you at least put in the OSGi  
manifest entries.  You do so using the maven/BND plugin I suspect.

This strikes me as a common service discovery pattern.  Off the top of  
my head I would think that a plugin that adds the necessary  
BundleActivator for legacy modules would be useful.

Another thought that flashed in my head is that in a buttoned down  
environment getting service notifications might be easier than getting  
access to every Bundle's class loader.


On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote:

> Cleaner, but the main problem is that it does not work with legacy  
> code.
> Will you rewrite the jaxb2 implementation to do that instead of  
> using the stax
> factory ? ;-)
> We've got tons of legacy stuff that use stax, or jaxb2 and i don't  
> see rewriting
> the whole lot as realistic.  it would also mean having an OSGi  
> specific thing
> everywhere we use a factory from a j2ee spec :-(
> On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera  
> <> wrote:
>> On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
>>> On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski < 
>>> >
>> wrote:
>>>> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <>
>> wrote:
>>>>> However, lots of these spec jars define factories (stax, saaj for
>> example)
>>>>> that use the META-INF/services/ discovery mechanism to find an
>>>>> implementation of the spec and load it.  This mechanism does not  
>>>>> fit
>> well in
>>>>> OSGi (really, it does not), mainly because usually, the  
>>>>> classloader
>>>>> containing the spec jar will not contain the implementation.
>>>>> I'd like to work on these spec jars so that they will contain an  
>>>>> OSGi
>>>>> BundleActivator that would change the behavior of these  
>>>>> factories when
>>>>> deployed in an OSGi environment (without changing the behavior in
>> other
>>>>> case).  The idea is that the activator would scan OSGi bundles  
>>>>> when
>> they are
>>>>> started to find META-INF/services and populate a map that would be
>> used by
>>>>> the factory when creating an object before using the standard
>> mechanism.
>>>> Just to ensure I'm following, you are about to create a activator  
>>>> that
>>>> would be a bundle listener (o.o.f.BundleListener) and whenever a
>>>> bundle is registered the activator will scan it for provided  
>>>> services?
>>>> Can you explain how osgi works now without these
>>>> META-INF/services-based services? Doesn't it use them at all?
>>> This is the tricky part.  The work we've done on the specs so far
>>> means that each spec
>>> is an OSGi bundle.   In OSGi, each bundle has each own classloader  
>>> and
>>> classloaders
>>> are not organized in a simple tree: if bundle A requires bundle B  
>>> and
>>> bundle B requires
>>> bundle C, it does not mean that C will be accessible to A.   
>>> Following so
>> far ?
>>> So, let's say I create a bundle that references the Stax Api.
>>> My bundle will have the geronimo stax api in its classpath.  The  
>>> stax
>>> implementation that
>>> I deploy will also have the stax api in its classpath, but it  
>>> won't be
>>> available to either
>>> the the stax api or my bundle.
>>> The problem happens when the stax api needs to find and create the
>>> implementation.
>>> Usually, the existing code won't be able to do that at all, because
>>> the META-INF/services
>>> and the implementation class are not available from the stax api
>> classloader.
>>> One way to work around that is (if the api uses the thread context
>>> classloader) to make sure
>>> my bundle includes the implementation in its classloader and make  
>>> sure
>>> the thread context
>>> classloader is correctly set.  This usually involves copying the
>>> META-INF/services/xx stuff
>>> in our bundle and explicitely referencing the implementation to make
>>> sure the classloader
>>> includes it.
>>> The problem is that it's a bit annoying to do that on all the  
>>> bundles
>>> and it does prevent
>>> swicthing implementations.
>>> So now, there is no need to reference the implementation from the
>>> bundle.  The spec jar bundle
>>> activator will use OSGi to find the META-INF/services/ entries each
>>> time a bundle is installed
>>> and if an implementation is used, will load the class through OSGi
>>> API, using the implementation
>>> bundle classloader instead of the spec jar classloader.
>> I think, just my personal opinion, that scouring bundles' META-INF/ 
>> services
>> entries is kinda klunky.  Could we not use a service/whiteboard  
>> approach
>> that is common in OSGi? When in Rome, do as the Romans do.
>> Let's assume that we go with the virgin spec jar wrapped in a bundle
>> paradigm I spoke of in a previous post.  Here the bundles that use  
>> the stax
>> api would register stax api service implementations.  The stax api  
>> would
>> catch those service registrations and properly configure the  
>> factory.   A
>> bit cleaner imo and you don't have to search every bundle.
>> Regards,
>> Alan
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:

View raw message