geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Geronimo specs jars in OSGi
Date Thu, 17 Apr 2008 15:05:46 GMT
I must be missing something.  That legacy code would not need to  
change.  The whiteboard pattern only obviates the need to scavenge  
every bundle the META-INF/services entries.  The rest works as you say.

But, as I think about it some more, I'm thinking that this is over  
engineering it.  Let's drop this aspect of the thread.

I still feel strongly that the virgin spec jar should be wrapped in a  
bundle.


Regards,
Alan

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

> i don't mean legacy jars but legacy *code*.
> If you have a jar which uses
>       javax.xml.stream.XMLInputFactory.newInstance()
> somewhere deep in the code, I don't really understand how using a  
> whiteboard
> pattern will solve the problem.  I'm not trying to make people rewrite
> everything,
> but rather make things easy for them to deploy their application  
> and keep the
> behavior they are used to see.
> it could be you want to deploy the jaxws-ri, jersey or any other  
> xml related
> technology that could use SAAJ, Stax, Jaxb2 ...
>
>
> On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera  
> <list@toolazydogs.com> wrote:
>> 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.
>>
>>
>>  Regards,
>>  Alan
>>
>>
>>
>>  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  
>>> <list@toolazydogs.com>
>> wrote:
>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>
>>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>


Mime
View raw message