You are right, this only happens in this one case, but still your
chances are at 50% hitting it :)
Would it be reasonable to go through all installed bundles and look if
the newly installed bundle
resolves an optional dependency. I have to admit though, this should be
more an issue of the
framework. Never the less I have seen this happen quite often but with
deployed bundles, not
with the ones provided as features.
> 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
>>>>>>>>>>>
>>>
>>
>
>
