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