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
