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
