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/
