On Fri, May 21, 2010 at 11:42, Lukasz Dywicki <[email protected]> wrote: > > Hello Guillaume, > > gnodet wrote: >> >> There is some work going on in the OSGi Alliance about multiple >> frameworks in one JVM (see >> http://www.osgi.org/Download/File?url=/download/osgi-core-4.3-early-draft1.pdf >> for more informations). This would enable to have a tree of OSGi >> frameworks instead of a single instance and would enable controlled >> sharing between a framework and its parent. This would enable a >> controlled level of isolation and could be used to make sure some >> features don't interfere with each other. That's one of the reason >> i'm not totally convinced about your proposal. If we'd were to use >> nested frameworks, each feature would have its own framework, so that >> would not map well to your proposal. >> > I didn't know that OSGi alliance published new draft so fast. > > I am not familar with current draft - but I found that bundle listeners will > be also scoped per framework - so when you'll install feature (and budnles) > in one other instances will don't know anything about this operation. >
Well, the idea would be that a feature would create a new nested framework, so all features would be visible from the top level. > > > gnodet wrote: >> >> The two other things i have in mind for features are: >> * give a lifecycle to a feature (start / stop) >> * allow more control on the bundles when installed (started level, >> start state) >> >> > I agree with you in your proposals: > +1 for feature lifecycle > +1 allow more control on the bundles when installed > > > gnodet wrote: >> >> * leverage obr to compute a transitive closure of the feature before >> installation >> The last one would allow a more loose definition of a feature but just >> specifying the list of key bundles and let the features service >> determine all the required dependencies and download / install them. > I don't know OBR and other stuff so I can't help and vote on this. I can > help in first two cases. OBR is a repository containing OSGi metadata. It would be used to compute the required dependencies. > > > gnodet wrote: >> >> FWIW, nested frameworks are not available yet in felix (there's only a >> prototype in an equinox branch), so we can't really use those now, but >> the other things should be possible to implement now. In particular, >> the use of OBR should now be possible since the new release as some >> acceptable performances. > > I think we can leave 4.3 and it's features and make Karaf good base to work > with OSGi 4.2. > From my side groving osgi complexity it's bad idea - I love KISS principle > and in my idea OSGi 4.2 is good example of simple and powerful environment. > We should wait until 4.3 will be in final stage to get them into Karaf. > > Best regards, > Lukasz Dywicki > -- > View this message in context: > http://old.nabble.com/Karaf-features-improvements-tp28622180p28631675.html > Sent from the Apache Felix - Dev mailing list archive at Nabble.com. > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
