On 11.11.2009 16:37:31 lukewpatterson wrote: > > > Jeremias Maerki-2 wrote: > > > > On 10.11.2009 18:26:37 lukewpatterson wrote: > >> > >> In my activator, I'm bundletracking looking for /META-INF/services > >> folders. > >> I wrap around the service-providing bundles with a custom ClassLoader and > >> then register them with my API's service factory. > >> > >> This approach seems to work fine except when the /META-INF/services are > >> provided exclusively from the Bundle-ClassPath entries. i.e. doesn't > >> work > >> when no /META-INF/services folder on root, but embedded jars on the > >> Bundle-ClassPath have the folder > >> > >> Is Bundle.findEntries(...) [1] supposed to look on the Bundle-Classpath? > > > > Are you trying to solve the same problem as I've done lately? > > See: http://www.jeremias-maerki.ch/development/osgi/jar-services.html > > Well, I didn't specifically look into the Bundle-Classpath issue in this > > context. I've turned the META-INF/services carrying JARs into full OSGi > > bundles. > > > > Yes Jeremias, I think what you've done is very close to what I'm looking > for. I think the restlet team is doing something kinda like this too [1].
Looks like we really have to find one good solution for everyone. Otherwise, everyone will continue to find a solution for themselves and we end up with dozens of extenders which scan lots of bundles. And that is a performance killer (see below). > I'm working with other teams which use jar SPI (they are kind enough to make > their stuff bundles, but don't care about OSGi beyond that point), and I > want a generic way of loading impls. The dynamism obviously wouldn't be > there, so I was thinking that the appropriate level of bundle state required > would merely be INSTALLED. But doesn't INSTALLED mean that the dependencies are not RESOLVED, yet? So instantiating plug-ins might actually cause ClassNotFoundExceptions. Especially for debugging, I find it useful, to stop a bundle and thereby making the plug-ins in that bundle unavailable. That's why I require the ACTIVE state to make the plug-ins available. > I started reading through your code and documentation. I was wondering if > it handles all the scenarios where a bundle can be updated, installed, > uninstalled. That was the intention. But I don't have much long-term experience, yet, but so far it seems to work just fine. > I was hoping to accomplish this generic lookup without requiring a special > manifest header, but I see how that introduces all sorts of complexities for > the implementation (even with BundleTracker and PackageAdmin). I've added an option (system property) to work without the manifest header but I've added the header because I've once done a profiling session of the service locator (implemented as an extender) found in ServiceMix4's spec bundles. The results: http://www.mail-archive.com/[email protected]/msg09270.html With the header I can avoid scanning the bundles that don't have any JAR services. Since JARs have to be made OSGi-compatible anyway, adding another header shouldn't be any trouble, I think. > [1] http://n2.nabble.com/OSGi-vs-Service-Provider-patterns-td2478338.html > and > http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/src/org/restlet/engine/internal/Activator.java?view=markup > and > -- > View this message in context: > http://old.nabble.com/Bundle.findEntries%28...%29-and-Bundle-Classpath-tp26287340p26302990.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
