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 >> > >
