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
<[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/
