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: [email protected] For additional commands, e-mail: [email protected]
