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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> wrote:
> >
> > >
> > >
> > > On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote:
> > >
> > >
> > >
> > > > On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski
> <[EMAIL PROTECTED]>
> > > >
> > > wrote:
> > >
> > > >
> > > >
> > > > > On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet <[EMAIL PROTECTED]>
> > > > >
> > > >
> > > 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/
