geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Geronimo specs jars in OSGi
Date Thu, 17 Apr 2008 14:30:26 GMT
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/

Mime
View raw message