Jeremias, Thanks for looking into the code and for doing this investigation work. If the Locator is indeed causing so much overhead, we do want to optimize that somehow. Do you an idea what part of the Locator code is causing the overhead?
As for creating a single Locator service in the system, the code now works with a static container for the SPI class information so we can't really use that as it is. We could probably use the OSGi Service registry instead of a static container class to hold the information. In the spec bundle, we would then either have a ServiceTracker to dynamically keep track of those registry entries or we would use a new OsgiLocator implementation that does the lookup dynamically. I guess one of the main problems is the fact that the classes in the META-INF/services would have to be instantiated to put them into the registry or we would have to create some kind of lazy-activate proxy that only creates the class when it's needed (avoiding the need for the bundle to be started until it's needed). I think the Blueprint services spec that's currently being built could help us there, but Guillaume knows a lot more about this so he can probably clarify what this would do for us. In the long run, it would probably make sense if this information would be in the the OSGi manifest instead of in another file inside the bundle. Not sure if we should consider that, because that would be a change that would have to go into all these things. We could solve it for Apache Felix Karaf (the-open-source-project-formerly-known-as ServiceMix Kernel) by making the Deployer do the conversion on the fly, but that would only solve it for Karaf and I guess we want a more generic solution. Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/26 Jeremias Maerki <[email protected]>: > 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 > >
