I've been experimenting a bit with the first part. and it seems I have something working. It consists of the following: * a modified karaf to support karaf activators (some kind of bundle activators but loaded from jars in the lib/ folder instead of bundles) * the spec jars dropped into lib/endorsed * a karaf activator (same as the one in the spec) but in a separate jar in the lib folder With that (and provided the spec defaults to the implementation in the JRE which require a few modifications for some), it seems I can safely install a bundle containing an implementation of any spec and have it used instead of the default jre implementation, without having to hide packages. The drawback is that such installation can't be done from inside karaf itself as it require rebooting the jre, but in the case of servicemix, it should not be a problem. Another benefit is that instead of having each spec jar scanning bundles, we only have a single activator for all specs deployed that way, which is slightly more efficient.
I'll commit the needed changes in karaf and specs so that we can further experiment and try to look at the second problem. On Thu, Nov 17, 2011 at 14:15, Guillaume Nodet <[email protected]> wrote: > Deploying java specs jars and providers is a bit tricky in osgi, even when > using the servicemix specs. > I think we face two problems: > * when deploying a spec bundle, we need to hide the packages from the > jre and by doing so we forbid the use of the implementation provided by the > jre > * when deploying an implementation, it won't be available until the > bundle is started but this constraint isn't captured > > For the first problem, I was thinking about deploying the specs jars in > the lib/endorsed dir so that they would be used.by the jre and enhance > them so that they would be able to discover the implementations in bundles > but also in the jre. This would work as they would use the same packages. > This may require some modifications in karaf, though i'm not sure yet. > > For the second point, i'm still hoping that the Generic Capabilities > introduced in osgi 4.3 can be leveraged fo that. I think that's aso > related to obr. > > Anyway, i'd like to find a solution to those problems, so any idea is of > course welcomed. > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
