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
