My email has been sent before I intended .... What I wanted to add is that the goal of the refresh mechanism is to be able to install a feature and make sure it works while minimizing the impact. If we were to do a global search, installing eventadmin would refresh the blueprint extender, and then all blueprint applications, so I'm not sure that's a good idea.
We could also imagine that creating a feature that depends on both http + eventadmin would trigger a refresh, but then the algorithm would become even more complicated. That's a bit tricky, but that's why the initial provisioning (boot features) install all features at the same time. On Mon, Dec 6, 2010 at 23:52, Guillaume Nodet <[email protected]> wrote: > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
