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:57:38 GMT
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 <gnodet@gmail.com> 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 <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>
>>>> 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>
>>>>>> After debugging, I'm not sure I do understand how this works. Does
>>>>>> 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>
>>>>>>>>> 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,
>>>>>>>>>> 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
>>>>>>>>>> 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>
>>>>>>>>>>> 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

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message