Yeah, not really sure how to handle that use case. I suppose we could add to the features service a scope for bundles to refresh and allow refreshing all bundles in the framework. Note that your use case only happen when you install http, then later eventadmin.
On Mon, Dec 6, 2010 at 23:46, Achim Nierbeck <[email protected]> wrote: > OK, now I understand. > So the issue is I do have the following > > Feature A containing bundle a > Feature B containing bundle b > which has a optional dependency on a. > But since A and B don't really have a common > root (in the concrete example it would be A the eventadmin feature > and B the http feature) you don't make those two > features dependent on each other. > Now how would this be handled. Is there an easy way of > handling this in future? > > >> Right, so it's a bit more focused ... >> >> So let's say we have: >> * Feature A containing bundle a >> * Feature B containing >> feature A >> bundle b >> so that bundle b solves an optional package for bundle a. >> >> Now, you install feature A, so bundle a gets resolved. >> You then install feature B. The algorithm will find all bundles that >> 'would have been installed' and check if one should be refreshed. >> In that case, bundle a should be refreshed. >> >> >> On Mon, Dec 6, 2010 at 23:30, Achim Nierbeck <[email protected]> wrote: >>> Well, taken the example I explained in KARAF-312 I have the following >>> >>> // First pass: include all bundles contained in these features >>> Set<Bundle> bundles = new HashSet<Bundle>(state.bundles); << >>> Here the current bundle eventadmin is added >>> bundles.removeAll(state.installed); <<< Here the same is removed >>> if (bundles.isEmpty()) { <<< therefore it is empty :( >>> return bundles; >>> } >>> >>>> It should start from the installed features set and check if one of >>>> the newly installed bundles solve an optional import of an already >>>> installed bundle, or if it is a fragment to attach on an already >>>> installed bundle. >>>> This avoid refreshing bundles that are not related to the newly >>>> installed features. >>>> >>>> On Mon, Dec 6, 2010 at 23:12, Achim Nierbeck <[email protected]> >>>> wrote: >>>>> After debugging, I'm not sure I do understand how this works. Does the >>>>> FeaturesServiceImpl#findBundlesToRefresh() method only work on the >>>>> newly installed feature set? I thought it helps me refreshing already >>>>> installed >>>>> bundles/features. >>>>> >>>>>> I will try to debug into this also, >>>>>> Jira Issue KARAF-312, does tell how to reproduce this. >>>>>> >>>>>>> I can try to investigate if you raise a JIRA and add the steps to >>>>>>> reproduce ... >>>>>>> >>>>>>> On Mon, Dec 6, 2010 at 11:13, Achim Nierbeck <[email protected]> >>>>>>> wrote: >>>>>>>> Ok, >>>>>>>> >>>>>>>> this was exactly what I was expecting from the behavior. >>>>>>>> Now with a concrete example. Working on Pax-Web, one of the bundles >>>>>>>> has an optional dependency to eventadmin service packages. >>>>>>>> Now the eventadmin service feature is deployed after the pax-web stuff. >>>>>>>> I do get an exception since the bundle that declared those packages as >>>>>>>> optional dependencies wasn't refreshed, but the service tracker already >>>>>>>> worked :( >>>>>>>> >>>>>>>> Thanks, Achim >>>>>>>> >>>>>>>>> So the features service tries to find out which bundles are to be >>>>>>>>> refreshed. >>>>>>>>> This is done by checking all bundles previously installed (note that >>>>>>>>> if you install several features, even including dependencies, bundles >>>>>>>>> should only be resolved at the end, so it only considers bundles that >>>>>>>>> were installed before the installation of the current features) for >>>>>>>>> optional packages that could be refreshed or new fragments. >>>>>>>>> The code is in FeaturesServiceImpl#findBundlesToRefresh() if you want >>>>>>>>> to have a look. >>>>>>>>> There are certainly some possible enhancements here, as it basically >>>>>>>>> try to do a poor-man's resolution (or at least try to check if >>>>>>>>> fragment's host and packages can be matched ...) I guess ideally, >>>>>>>>> we'd do a fake resolution, and this might become possible with the >>>>>>>>> next OBR generation, but not really now. >>>>>>>>> >>>>>>>>> On Sun, Dec 5, 2010 at 21:36, Achim Nierbeck >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> how does the refresh mechanism work for features? >>>>>>>>>> For example you have a features A deployed and deploy another >>>>>>>>>> features B. >>>>>>>>>> I sometimes see that certain bundles of features A are refreshed. >>>>>>>>>> How is >>>>>>>>>> this >>>>>>>>>> accomplished? How am I able to trigger something like this? >>>>>>>>>> >>>>>>>>>> Greetings, Achim >>>>>>>>>> >>>> >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
