You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Achim Nierbeck <bc...@googlemail.com> on 2010/12/05 21:36:16 UTC
features refresh mechanism?
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
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <gn...@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 <bc...@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 <bc...@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 <bc...@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 <bc...@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 <bc...@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
>>
>
>
Re: features refresh mechanism?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@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 <bc...@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 <bc...@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 <bc...@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 <bc...@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 <bc...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <bc...@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 <bc...@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 <bc...@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 <bc...@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 <bc...@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
>>>>>>>>>>>
>>>
>>
>
>
Re: features refresh mechanism?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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 <bc...@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 <bc...@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 <bc...@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 <bc...@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
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <bc...@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 <bc...@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 <bc...@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 <bc...@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
>>>>>>>>>
>>>
>>
>
>
Re: features refresh mechanism?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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 <bc...@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 <bc...@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 <bc...@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
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@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 <bc...@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 <bc...@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 <bc...@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
>>>>>>>
>>
>
>
Re: features refresh mechanism?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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 <bc...@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 <bc...@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
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <bc...@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 <bc...@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
>>>>>
>>
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <bc...@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 <bc...@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
>>>>
>>>
>>
>
>
Re: features refresh mechanism?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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 <bc...@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
Re: features refresh mechanism?
Posted by Achim Nierbeck <bc...@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, 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 <bc...@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
>>
>
>
Re: features refresh mechanism?
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <bc...@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