Thanks for your response, Gert.
47% of the time during scanning is spent in Bundle.findEntries()
(org.apache.felix.framework.BundleImpl.findEntries(String, String, boolean)).
Another 25% is spent in Enumeration.nextElement
(org.apache.felix.framework.FindEntriesEnumeration.nextElement())
As for providing the discovered service implementations, I think it
can make sense to just publish a special OSGi service (per class) that
allows access to the Class and allows to create a new instance, for
example:
public interface JarServiceFactory {
Class getImplementationClass();
Object createInstance() throws InstantiationException, IllegalAccessException;
}
I've started writing something like that but I've put it aside in favor
of another task I'm currently working on. I intend to get back to it
soon.
I think it would be possible and to go a step further and use a special
header to indicate certain implementation classes that should be
instantiated directly and published as OSGi service.
One problem I see is that this probably only works if the name of the
file in META-INF/services matches the fully qualified name of a common
base class or interface (there's no requirement for that).
I'm not sure how exactly the blueprint services will help here. I have
heard about the topic but haven't taken a closer look, yet.
As you hinted at, I wouldn't want the solution to be tied to Karaf. I'd
prefer one based on standard OSGi infrastructure.
On 27.05.2009 12:55:23 Gert Vanthienen wrote:
> 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
> >
> >
Jeremias Maerki
