Missed dev@ as a recipient. On Fri, Nov 18, 2011 at 16:25, Guillaume Nodet <[email protected]> wrote:
> > > On Fri, Nov 18, 2011 at 16:19, Daniel Kulp <[email protected]> wrote: > >> On Friday, November 18, 2011 8:59:48 AM Guillaume Nodet wrote: >> > 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), >> >> Can I have more details on that last point? Keep in mind, the class >> names >> for the defaults are very different depending on the JDK in use. Thus, >> you >> cannot just change the default classname in spec jar as that may not work >> on >> the JDK. You may need to find a way to actually get it to dig into the >> Provider factory thing in the JDK to get the right class name. >> > > Yes, that's really one point I still have to investigate as I'd like to be > able to use the JRE provided implementations when possible. > I don't really see any other solution than to hardcode the names as the > implementation class names aren't available easily (I really don't want to > start hacking into byte code to find the value of parameter calls). > I suppose that would mean supporting a limited set of JDK that we would > have tested our default values with. > > >> >> Dan >> >> >> > 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 >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> > > > > -- > ------------------------ > 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
