Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <DCEB0864-C89F-4957-B143-516550FDB1AF@toolazydogs.com>
From: "Alan D. Cabrera" <list@toolazydogs.com>
To: dev@geronimo.apache.org
In-Reply-To: <b23ecedc0804170654w61b32d75u25f4387c52257496@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Geronimo specs jars in OSGi
Date: Thu, 17 Apr 2008 07:24:32 -0700
References: <b23ecedc0804160820n1e13d678gb0d52f3ace08efa3@mail.gmail.com>
 <1b5bfeb50804170427i563f20c0nc8d1b6aea7523d66@mail.gmail.com>
 <b23ecedc0804170654w61b32d75u25f4387c52257496@mail.gmail.com>


On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:

> On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski <jacek@laskowski.net.pl 
> > wrote:
>> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <gnodet@gmail.com>  
>> 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