As stated in my other reply, I think this should be manly be resolved by
the framework.
Regarding your objection because of the blueprint bundles etc. If I do a
restart of the
server these bundles do get refreshed and have their optional
dependencies set.
And the blueprint bundles to fire events :) I was able to see with the
eventadmin webconsole :)
> My email has been sent before I intended ....
>
> What I wanted to add is that the goal of the refresh mechanism is to
> be able to install a feature and make sure it works while minimizing
> the impact.
> If we were to do a global search, installing eventadmin would refresh
> the blueprint extender, and then all blueprint applications, so I'm
> not sure that's a good idea.
>
> We could also imagine that creating a feature that depends on both
> http + eventadmin would trigger a refresh, but then the algorithm
> would become even more complicated.
>
> That's a bit tricky, but that's why the initial provisioning (boot
> features) install all features at the same time.
>
> On Mon, Dec 6, 2010 at 23:52, Guillaume Nodet <[email protected]> wrote:
>> 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
>>>>>>>>>>>>
>>>>
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
