karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: features refresh mechanism?
Date Mon, 06 Dec 2010 22:52:40 GMT
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 <bcanhome@googlemail.com> 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 <bcanhome@googlemail.com> 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 <bcanhome@googlemail.com>
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 <bcanhome@googlemail.com>
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 <bcanhome@googlemail.com>
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

Mime
View raw message