I'm currently looking into making certain libraries OSGi-capapable which are to date using the META-INF/services mechanism for detecting plug-ins. In this context I noticed the locator classes used by the spec bundles SMX4 publishes. I've thought about doing something similar but was surprised to find a copy of the two classes in each spec bundle. Each activator is registering a synchronous bundle listener which scans for all files in META-INF/services. I suspected this might be bad for (startup) performance so I profiled the whole thing:
Profiling showed that the register() method of the Activator is called 966 times for (currently) 138 bundles. 966 / 138 = 7. Currently, seven spec JARs in my application are all using that approach. The profiler determined that 5% of the startup time is used just for this. This will increase with every spec JAR or normal bundle that is added to the application. I wonder if it were not possible to keep the activator as a separate locator bundle that all spec bundles could use together. That way, the SPI files only need to be scanned for once per bundle. I haven't investigated the technical implications to any depth, yet. I just wanted to gather some thoughts. I could actually then use that approach, too, for detecting plug-in implementations in the various bundles. For example, Apache FOP & Batik are using the SPI mechanism extensively and not just for looking up a default factory implementation. Various plug-ins extend the two with support for new output formats, image formats, etc. etc. I wonder if it makes sense to make the locator into a more general utility (maybe in Felix or Commons or Lab). I've started writing a very small set of interfaces and classes that would help abstracting the use of JAR SPI plug-ins inside and outside an OSGi environment. After seeing the spec locator Activator I'm somewhat hesitant to create yet another synchronous bundle listener that has to scan META-INF/services. Another thought I had: Since scanning META-INF/services seems rather expensive, a bundle header entry [1] that signals the presense of files in META-INF/services could enable to early return from the listener. Of course, that requires all affected bundles to be changed. Not ideal, I know. Still, I think it is worth thinking about. [1] Example: JAR-Service-Provider: true I'm grateful for any thoughts on the matter. Thanks, Jeremias Maerki
