xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Running XML Graphics products on OSGi
Date Tue, 03 Nov 2009 22:13:44 GMT
On 03.11.2009 21:51:53 Simon Pepping wrote:
> On Tue, Nov 03, 2009 at 05:18:05PM +0100, Jeremias Maerki wrote:
> > Over the past few months, I've started to get FOP, Batik and Commons
> > running in an OSGi environment. The first easy step is to just add the
> > necessary metadata to the manifest. However, that is not enough in the
> > case here. The problem: we're using the JAR Service Provider mechanism
> > from the JAR specification (META-INF/services directory in the JARs).
> > 
> > OSGi doesn't have a hierarchical class loader setup like traditional
> > Java applications which is why FOP, for example, may not see all
> > available plug-ins anymore if they are not compiled together into a
> > monster-JAR.
> > 
> > The solution was to build an abstraction layer above the direct access
> > to the META-INF/services files. In an OSGi-environment, a special
> > component (a so-called extender) will watch all available bundles (=JARs)
> > in the application. If it finds plug-ins it make them available despite
> > the class loader isolation. Well, that's simply the executive summary.
> > In the end, this is a replacement for the "Services" class in XML
> > Graphics Commons which we use today.
> 
> I am surprised that such a utility does not yet exist. Surely FOP is
> not the only application that loads plug-ins. Eclipse is based on
> plug-ins, but I suppose they solve the problem because you have to
> install eclips plug-ins in known places.

Not sure I understanding what you're trying to say. OSGi is all about
services, plug-ins or whatever you call it. That's one of the great
things about it. Eclipse is based on OSGi but their way of doing
plug-ins is actually a bit special because Eclipse has a non-OSGi past
which I've read is still creaping around in today's design. In a "normal"
OSGi environment, you just install a new bundle and that bundle may
register a service with the OSGi service registry. And that service may
be a plug-in that can then be used by some other component.

On the other side (non-OSGi), we've solved the plug-in thing in XML
Graphics using the JAR service provider mechanism. Worked fine for us so
far as long as we're staying with the default hierarchical class loaders.

What was missing was something that makes the JAR service providers work
in an OSGi environment. There is a sub-specification in the OSGi
compendium that tries to address the discovery of XML parsers.
SAXParserFactory and DocumentBuilderFactory implementations are normally
also discovered through the JAR service provider mechanism in plain Java.
At the moment, most OSGi applications can just switch parsers by using
the "Endorsed Standards Override Mechanism" but not by deploying an XML
parser as normal OSGi bundle. Not very OSGi-like. But there's no OSGi
specification that defines how the JAR service provider mechanism in
general is mapped into OSGi. In Apache Felix, there have been some
efforts for discovering JAXB implementations, for example, but in these
cases, it's always about finding one implementation (i.e. the default
implementation). We actually need multiple implementations/plug-ins per
interface, not just one. And that simply wasn't covered (in OSGi land),
yet, as far as my research showed. That's why I built this "bridge". FOP
doesn't have to adopt OSGi (nor have a runtime dependency on any of its
spec JARs), but it can be made fully OSGi-compatible so someone can one
day just drop Barcode4J in a deployment hotfolder, Felix picks it up and
deploys it as a bundle and FOP can start immediately producing barcodes
despite the class loader barriers in OSGi. All at runtime. You can even
update the plug-in without restarting the application.

Not sure if I'm making sense.

Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message