Hi Max On 12.11.2009 11:12:02 Max Berger wrote: > Jeremias, > > a late reply, but hopefully still valid: > > - If you use OSGi, you will either need to implement a simplified > version for detecting plug-ins, or introduce additional dependencies > (apache felix). Both would increase the size of xmlgraphics-commons, so > should be carefully considered.
Yes, there will be an increase of classes necessary to handle this (-1 Services.java in XGC, and 1+ JAR of 28KB (15 classes)), but no, there won't be a dependency on Apache Felix or any other OSGi specific class in XGC. That's what my abstraction layer is all about: shielding FOP/Batik from OSGi-specifics but enabling them to run in an OSGi environment. > - at least until fop 1.0 plug-ins written using the service approach > should still be loaded. My abstraction layer is designed to be a complete replacement of the Services class but in terms of plug-in handling almost nothing changes. The META-INF/service is still used as before. Instead of getting an iterator with all plug-in classes you set up a simple listener which gets notified if a plug-in becomes available or goes away. I don't propose to suddenly use OSGi services at all. This whole thing will still work completely without a single OSGi or Felix class in the classpath for the big majority of users who still don't use OSGi. > - I like the OSGi approach as it is currently widely used. Not as widely as you might think. Otherwise, people would have come screaming for OSGi metadata in FOP a long time ago. But yeah, OSGi is very cool and adoption is spreading fast. > As an idea: If you submit your code to apache felix maybe they could > produce some kind of "felix lite" version, which would be the minimal > osgi environment needed to replace the current "Service" class? This > would remove my first point above I think with my above comments I've already addressed that, but without the need for a "Felix lite". > Max > > > Jeremias Maerki schrieb: > > 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. > > > > Anyway, I've published today an initial version of that abstraction > > layer on my website [1]. I've started locally to change XML Graphics > > Commons, so Commons can see the ImageConverter plug-ins provided by FOP > > in an OSGi environment. With that alone I've already been able to run > > FOP & Batik in OSGi. I'll have to do more of the same for all other > > extension points. That means changes to all three products (including > > Batik). Also, extension authors will have to make their plug-ins > > OSGi-capable if they want their extensions to work in an OSGi > > environment. > > > > I'm going to wait a bit before proposing any patches. I first want to > > get some feedback on the abstraction layer from the Felix community > > where I've also posted the link. Felix might be one possible location > > where this thing could be maintained. Since it also works completely > > without OSGi, Apache Commons could be another option. That should be > > sorted out in the following weeks. I just wanted to let everyone know > > that this is something I would like to address in the near future. > > > > If you want to know what OSGi is, take a quick look on the Wikipedia > > page [2]. If you're an Eclipse user, you're already working on OSGi, > > even though you may not even know. > > > > [1] http://www.jeremias-maerki.ch/development/osgi/jar-services.html > > [2] http://en.wikipedia.org/wiki/OSGi > > > > > > > > Jeremias Maerki > > > > -- > http://max.berger.name/ > OpenPGP ID: C93C5700 Fpr: AB6638CE472A499B3959 ADA2F989A2E5C93C5700 > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
