You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Andreas Pieber <an...@gmail.com> on 2012/09/27 18:58:14 UTC
Feature Service PHYSIKOdata bundle startup order
Hey guys,
First of all, just to bring everyone at the same lvl: If we install
features all bundles in the feature(s) are installed and then started
one after the other, in the order as they had been defined in the
features.
While in theory it should not happen there are situations where we (in
our software) depend that those features are started at least per
feature in the order in which they had been added. If I understand the
CXF feature structure correctly it's also required for them. By a bug
last week on the trunk I discovered this explicit requirement for our
software. Starting by this discovery we've started a discussion if it
wouldn't be better if we consider the startLvl during the feature
startup. So, I hacked up a solution and tested it with several
different softwares I've access to and it seamed to work pretty well.
I've attached the patch to [1] and would really like to hear what you
think about it.
Kind regards,
Andreas
[1] https://issues.apache.org/jira/browse/KARAF-1878
Re: Feature Service PHYSIKOdata bundle startup order
Posted by "Jamie G." <ja...@gmail.com>.
Yes, quite interesting. Finer grained control can't hurt as long as
its very well documented.
Cheers,
Jamie
On Thu, Sep 27, 2012 at 2:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Andreas,
>
> interesting. I will take a look on the patch tomorrow afternoon.
>
> Thanks !
> Regards
> JB
>
>
> On 09/27/2012 06:58 PM, Andreas Pieber wrote:
>>
>> Hey guys,
>>
>> First of all, just to bring everyone at the same lvl: If we install
>> features all bundles in the feature(s) are installed and then started
>> one after the other, in the order as they had been defined in the
>> features.
>>
>> While in theory it should not happen there are situations where we (in
>> our software) depend that those features are started at least per
>> feature in the order in which they had been added. If I understand the
>> CXF feature structure correctly it's also required for them. By a bug
>> last week on the trunk I discovered this explicit requirement for our
>> software. Starting by this discovery we've started a discussion if it
>> wouldn't be better if we consider the startLvl during the feature
>> startup. So, I hacked up a solution and tested it with several
>> different softwares I've access to and it seamed to work pretty well.
>>
>> I've attached the patch to [1] and would really like to hear what you
>> think about it.
>>
>> Kind regards,
>> Andreas
>>
>> [1] https://issues.apache.org/jira/browse/KARAF-1878
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Andreas,
interesting. I will take a look on the patch tomorrow afternoon.
Thanks !
Regards
JB
On 09/27/2012 06:58 PM, Andreas Pieber wrote:
> Hey guys,
>
> First of all, just to bring everyone at the same lvl: If we install
> features all bundles in the feature(s) are installed and then started
> one after the other, in the order as they had been defined in the
> features.
>
> While in theory it should not happen there are situations where we (in
> our software) depend that those features are started at least per
> feature in the order in which they had been added. If I understand the
> CXF feature structure correctly it's also required for them. By a bug
> last week on the trunk I discovered this explicit requirement for our
> software. Starting by this discovery we've started a discussion if it
> wouldn't be better if we consider the startLvl during the feature
> startup. So, I hacked up a solution and tested it with several
> different softwares I've access to and it seamed to work pretty well.
>
> I've attached the patch to [1] and would really like to hear what you
> think about it.
>
> Kind regards,
> Andreas
>
> [1] https://issues.apache.org/jira/browse/KARAF-1878
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Andreas Pieber <an...@gmail.com>.
Ok just checked again. For insert treeset O(log n) hash set O(n), so for
unser the treeset is faster, while for read the hashset is faster O(1) vs
O(log n). Since we don't read single elements but only iterate the treeset
is definitely the faster options. Independently of speed I'm also +1 for
the tree since the it would only inhance the current behavior instead of
completely changing it.
Kind regards, Andreas
On Sep 28, 2012 9:45 AM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> I also agree that backporting the new behaviour and setting the old as
> default makes sense.
> I am also fine with setting the new behaviour as default on trunk. I think
> on trunk we do not even need a switch.
>
> Btw. I would like to replace the TreeSet with a HashSet on trunk again as
> we do not need the order there anymore.
> This is probably faster and makes testing a bit simpler again.
>
> Christian
>
> On 09/28/2012 05:43 AM, Andreas Pieber wrote:
>
>> Hey Freeman,
>>
>> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com>
>> wrote:
>>
>>> It's a good idea.
>>>
>> Thanks :-)
>>
>> And how about we introduce an property for FeaturesServiceImpl, and in
>>> etc/org.apache.karaf.features.**cfg we get chance to configure this
>>> property so that we can keep behavior as is or use the new behavior you
>>> introduced here, just in case some user somehow still wanna use current
>>> behavior.
>>>
>> Definitely +1 here; I can add this before pushing the changes. Since
>> the change is quite limited this should be quite simple.
>>
>> And I suggest the default behavior is keep as is.
>>>
>> Well, that's a point I want to discuss. I'm not sure if the current
>> default behavior is what really meets the expectations. For example,
>> if you give the cxf or amq feature.xml files a shot there are quite a
>> lot of startlvl annotations for bundles. I think that it still work
>> with the current behavior is more luck than anything else :-) In
>> addition the new behavior will not affect most of the current
>> applications. More over I think it's the "more sane" behavior to
>> consider the startlvl per default and use the old one as a fallback
>> behavior if it doesn't work out for you in any specific reason.
>>
>> What would make sense for me is backporting the change to 2.3 (or 2.4)
>> and use the old behavior there per default; but for the master I think
>> we could risk this slight change of the default behavior.
>>
>> Does this makes sense to you?
>>
>> I think the features/core/src/main/**resources/OSGI-INF/blueprint/**gshell-features.xml
>>> need be updated accordingly.
>>>
>> For the new property I need to introduce you mean?
>>
>> My 2 cents
>>>
>> Warmly welcomed, as always; thanks!
>>
>> Kind regards,
>> Andreas
>>
>> Best Regards
>>> Freeman
>>> －－－－－－－－－－－－－
>>> Freeman Fang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>> Web: http://fusesource.com | http://www.redhat.com/
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>> http://blog.sina.com.cn/u/**1473905042<http://blog.sina.com.cn/u/1473905042>
>>> weibo: http://weibo.com/u/1473905042
>>>
>>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>>
>>> Hey guys,
>>>>
>>>> First of all, just to bring everyone at the same lvl: If we install
>>>> features all bundles in the feature(s) are installed and then started
>>>> one after the other, in the order as they had been defined in the
>>>> features.
>>>>
>>>> While in theory it should not happen there are situations where we (in
>>>> our software) depend that those features are started at least per
>>>> feature in the order in which they had been added. If I understand the
>>>> CXF feature structure correctly it's also required for them. By a bug
>>>> last week on the trunk I discovered this explicit requirement for our
>>>> software. Starting by this discovery we've started a discussion if it
>>>> wouldn't be better if we consider the startLvl during the feature
>>>> startup. So, I hacked up a solution and tested it with several
>>>> different softwares I've access to and it seamed to work pretty well.
>>>>
>>>> I've attached the patch to [1] and would really like to hear what you
>>>> think about it.
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> [1] https://issues.apache.org/**jira/browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878>
>>>>
>>>
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Andreas Pieber <an...@gmail.com>.
sorry for the delay... patches are uploaded to [1] and the itests are running.
I'll apply on Tuesday if there are no additional remarks.
Kind regards,
Andreas
[1] https://issues.apache.org/jira/browse/KARAF-1878
On Sat, Sep 29, 2012 at 5:19 AM, Freeman Fang <fr...@gmail.com> wrote:
> +1
>
> Thanks
> －－－－－－－－－－－－－
> Freeman Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
> On 2012-9-28, at 下午11:42, Andreas Pieber wrote:
>
>> OK, just to conclude that part of the discussion: After some discussion on
>> IRC Christian and I both think that the TreeSet is the better solution of
>> the HashSet since it does only optimize the bahvior instead of completely
>> changing it. We all know that startup dependencies are a pretty bad thing
>> and that only the start lvl should be used to handle this problem, but
>> still, we simply don't want to break some big not so well designed business
>> applications since those guys are definitely going to blame Karaf...
>>
>> Therefore I would propose the following: (a) handle the start lvl per
>> default on trunk and add a deprecated property to switch to the old
>> behavior ignoring the startLvl. We can remove it for Karaf 4.0. In addition
>> I'll backport the patch to 2.3 and use the old behavior which ignores start
>> lvls completely. The same property can be used here to activate the
>> startlvl handling. In addition I'll update the documentation with this new
>> behavior. I'll finish all those things first tomorrow morning, attach the
>> patches to the current JIRA and give you at least till Tuesday to test and
>> review the patches before I apply them.
>>
>> Anyone OK by this?
>>
>> Kind regards,
>> Andreas
>> On Sep 28, 2012 11:52 AM, "Christian Schneider" <ch...@die-schneider.net>
>> wrote:
>>
>>> Hi Andreas,,
>>>
>>> sorry my fault. I meant the HashSet but obviously this would not help as
>>> we then would have to mock the bundle.equals method I think.
>>>
>>> So the more important thing would be to replace the Bundle object with
>>> just its id. As obviously we would
>>> not need to mock Longs but we currently have to mock the Bundle objects.
>>> So in that case I think it would not matter much if we use TreeSet or
>>> HashSet.
>>>
>>> But I am not sure if this is easy to do or would have some other problems.
>>>
>>> Christian
>>>
>>> On 09/28/2012 11:45 AM, Andreas Pieber wrote:
>>>
>>>> Ok, now I get you. You want to use a hash map instead of an treeset (it
>>>> was
>>>> a hashset(!)) temporary. But I'm not quite sure how this will help in
>>>> testing? Neither by storing the id in a set nor in a hash map? Please
>>>> explain.
>>>>
>>>> Kind regards,
>>>> Andreas
>>>> On Sep 28, 2012 11:31 AM, "Christian Schneider" <ch...@die-schneider.net>
>>>> wrote:
>>>>
>>>>
>>>>
>>>
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Freeman Fang <fr...@gmail.com>.
+1
Thanks
－－－－－－－－－－－－－
Freeman Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-9-28, at 下午11:42, Andreas Pieber wrote:
> OK, just to conclude that part of the discussion: After some discussion on
> IRC Christian and I both think that the TreeSet is the better solution of
> the HashSet since it does only optimize the bahvior instead of completely
> changing it. We all know that startup dependencies are a pretty bad thing
> and that only the start lvl should be used to handle this problem, but
> still, we simply don't want to break some big not so well designed business
> applications since those guys are definitely going to blame Karaf...
>
> Therefore I would propose the following: (a) handle the start lvl per
> default on trunk and add a deprecated property to switch to the old
> behavior ignoring the startLvl. We can remove it for Karaf 4.0. In addition
> I'll backport the patch to 2.3 and use the old behavior which ignores start
> lvls completely. The same property can be used here to activate the
> startlvl handling. In addition I'll update the documentation with this new
> behavior. I'll finish all those things first tomorrow morning, attach the
> patches to the current JIRA and give you at least till Tuesday to test and
> review the patches before I apply them.
>
> Anyone OK by this?
>
> Kind regards,
> Andreas
> On Sep 28, 2012 11:52 AM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
>> Hi Andreas,,
>>
>> sorry my fault. I meant the HashSet but obviously this would not help as
>> we then would have to mock the bundle.equals method I think.
>>
>> So the more important thing would be to replace the Bundle object with
>> just its id. As obviously we would
>> not need to mock Longs but we currently have to mock the Bundle objects.
>> So in that case I think it would not matter much if we use TreeSet or
>> HashSet.
>>
>> But I am not sure if this is easy to do or would have some other problems.
>>
>> Christian
>>
>> On 09/28/2012 11:45 AM, Andreas Pieber wrote:
>>
>>> Ok, now I get you. You want to use a hash map instead of an treeset (it
>>> was
>>> a hashset(!)) temporary. But I'm not quite sure how this will help in
>>> testing? Neither by storing the id in a set nor in a hash map? Please
>>> explain.
>>>
>>> Kind regards,
>>> Andreas
>>> On Sep 28, 2012 11:31 AM, "Christian Schneider" <ch...@die-schneider.net>
>>> wrote:
>>>
>>>
>>>
>>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Andreas Pieber <an...@gmail.com>.
OK, just to conclude that part of the discussion: After some discussion on
IRC Christian and I both think that the TreeSet is the better solution of
the HashSet since it does only optimize the bahvior instead of completely
changing it. We all know that startup dependencies are a pretty bad thing
and that only the start lvl should be used to handle this problem, but
still, we simply don't want to break some big not so well designed business
applications since those guys are definitely going to blame Karaf...
Therefore I would propose the following: (a) handle the start lvl per
default on trunk and add a deprecated property to switch to the old
behavior ignoring the startLvl. We can remove it for Karaf 4.0. In addition
I'll backport the patch to 2.3 and use the old behavior which ignores start
lvls completely. The same property can be used here to activate the
startlvl handling. In addition I'll update the documentation with this new
behavior. I'll finish all those things first tomorrow morning, attach the
patches to the current JIRA and give you at least till Tuesday to test and
review the patches before I apply them.
Anyone OK by this?
Kind regards,
Andreas
On Sep 28, 2012 11:52 AM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> Hi Andreas,,
>
> sorry my fault. I meant the HashSet but obviously this would not help as
> we then would have to mock the bundle.equals method I think.
>
> So the more important thing would be to replace the Bundle object with
> just its id. As obviously we would
> not need to mock Longs but we currently have to mock the Bundle objects.
> So in that case I think it would not matter much if we use TreeSet or
> HashSet.
>
> But I am not sure if this is easy to do or would have some other problems.
>
> Christian
>
> On 09/28/2012 11:45 AM, Andreas Pieber wrote:
>
>> Ok, now I get you. You want to use a hash map instead of an treeset (it
>> was
>> a hashset(!)) temporary. But I'm not quite sure how this will help in
>> testing? Neither by storing the id in a set nor in a hash map? Please
>> explain.
>>
>> Kind regards,
>> Andreas
>> On Sep 28, 2012 11:31 AM, "Christian Schneider" <ch...@die-schneider.net>
>> wrote:
>>
>>
>>
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Andreas,,
sorry my fault. I meant the HashSet but obviously this would not help as
we then would have to mock the bundle.equals method I think.
So the more important thing would be to replace the Bundle object with
just its id. As obviously we would
not need to mock Longs but we currently have to mock the Bundle objects.
So in that case I think it would not matter much if we use TreeSet or
HashSet.
But I am not sure if this is easy to do or would have some other problems.
Christian
On 09/28/2012 11:45 AM, Andreas Pieber wrote:
> Ok, now I get you. You want to use a hash map instead of an treeset (it was
> a hashset(!)) temporary. But I'm not quite sure how this will help in
> testing? Neither by storing the id in a set nor in a hash map? Please
> explain.
>
> Kind regards,
> Andreas
> On Sep 28, 2012 11:31 AM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Andreas Pieber <an...@gmail.com>.
Ok, now I get you. You want to use a hash map instead of an treeset (it was
a hashset(!)) temporary. But I'm not quite sure how this will help in
testing? Neither by storing the id in a set nor in a hash map? Please
explain.
Kind regards,
Andreas
On Sep 28, 2012 11:31 AM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> Hi Andreas,
>
> hash maps should be generally O(1) while tree maps should be O(log n).
> I don't think though the speed is the big issue. The thing I really would
> like to improve is the testability.
>
> I wonder if we could use just the bundle id in the maps instead of the
> full bundle object. That should make it even easier to test.
>
> Christian
>
> On 09/28/2012 10:04 AM, Andreas Pieber wrote:
>
>> I'm not really happy with the hash map there. Does any one know the big O
>> of tree set vs hash set? Curious if the insert is really that much faster.
>> Besides, right now the algorithm keeps the base order and ONLY reschedule
>> bundles with a different start lvl. A hash set with only the sorting
>> afterwards will destroy the base order. So rather +1 to keep the tree set.
>>
>> Kind regards,
>> Andreas
>> On Sep 28, 2012 9:45 AM, "Christian Schneider" <ch...@die-schneider.net>
>> wrote:
>>
>> I also agree that backporting the new behaviour and setting the old as
>>> default makes sense.
>>> I am also fine with setting the new behaviour as default on trunk. I
>>> think
>>> on trunk we do not even need a switch.
>>>
>>> Btw. I would like to replace the TreeSet with a HashSet on trunk again as
>>> we do not need the order there anymore.
>>> This is probably faster and makes testing a bit simpler again.
>>>
>>> Christian
>>>
>>> On 09/28/2012 05:43 AM, Andreas Pieber wrote:
>>>
>>> Hey Freeman,
>>>>
>>>> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com>
>>>> wrote:
>>>>
>>>> It's a good idea.
>>>>>
>>>>> Thanks :-)
>>>>
>>>> And how about we introduce an property for FeaturesServiceImpl, and in
>>>>
>>>>> etc/org.apache.karaf.features.****cfg we get chance to configure this
>>>>> property so that we can keep behavior as is or use the new behavior you
>>>>> introduced here, just in case some user somehow still wanna use current
>>>>> behavior.
>>>>>
>>>>> Definitely +1 here; I can add this before pushing the changes. Since
>>>> the change is quite limited this should be quite simple.
>>>>
>>>> And I suggest the default behavior is keep as is.
>>>> Well, that's a point I want to discuss. I'm not sure if the current
>>>> default behavior is what really meets the expectations. For example,
>>>> if you give the cxf or amq feature.xml files a shot there are quite a
>>>> lot of startlvl annotations for bundles. I think that it still work
>>>> with the current behavior is more luck than anything else :-) In
>>>> addition the new behavior will not affect most of the current
>>>> applications. More over I think it's the "more sane" behavior to
>>>> consider the startlvl per default and use the old one as a fallback
>>>> behavior if it doesn't work out for you in any specific reason.
>>>>
>>>> What would make sense for me is backporting the change to 2.3 (or 2.4)
>>>> and use the old behavior there per default; but for the master I think
>>>> we could risk this slight change of the default behavior.
>>>>
>>>> Does this makes sense to you?
>>>>
>>>> I think the features/core/src/main/****resources/OSGI-INF/blueprint/*
>>>> ***gshell-features.xml
>>>>
>>>>> need be updated accordingly.
>>>>>
>>>>> For the new property I need to introduce you mean?
>>>>
>>>> My 2 cents
>>>> Warmly welcomed, as always; thanks!
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> Best Regards
>>>>
>>>>> Freeman
>>>>> －－－－－－－－－－－－－
>>>>> Freeman Fang
>>>>>
>>>>> Red Hat, Inc.
>>>>> FuseSource is now part of Red Hat
>>>>> Web: http://fusesource.com | http://www.redhat.com/
>>>>> Twitter: freemanfang
>>>>> Blog: http://freemanfang.blogspot.****com<http://freemanfang.**
>>>>> blogspot.com <http://freemanfang.blogspot.com>>
>>>>> http://blog.sina.com.cn/u/****1473905042<http://blog.sina.com.cn/u/**1473905042>
>>>>> <http://blog.sina.**com.cn/u/1473905042<http://blog.sina.com.cn/u/1473905042>
>>>>> >
>>>>> weibo: http://weibo.com/u/1473905042
>>>>>
>>>>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>>>>
>>>>> Hey guys,
>>>>>
>>>>>> First of all, just to bring everyone at the same lvl: If we install
>>>>>> features all bundles in the feature(s) are installed and then started
>>>>>> one after the other, in the order as they had been defined in the
>>>>>> features.
>>>>>>
>>>>>> While in theory it should not happen there are situations where we (in
>>>>>> our software) depend that those features are started at least per
>>>>>> feature in the order in which they had been added. If I understand the
>>>>>> CXF feature structure correctly it's also required for them. By a bug
>>>>>> last week on the trunk I discovered this explicit requirement for our
>>>>>> software. Starting by this discovery we've started a discussion if it
>>>>>> wouldn't be better if we consider the startLvl during the feature
>>>>>> startup. So, I hacked up a solution and tested it with several
>>>>>> different softwares I've access to and it seamed to work pretty well.
>>>>>>
>>>>>> I've attached the patch to [1] and would really like to hear what you
>>>>>> think about it.
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> [1] https://issues.apache.org/****jira/browse/KARAF-1878<https://issues.apache.org/**jira/browse/KARAF-1878>
>>>>>> <https:/**/issues.apache.org/jira/**browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878>
>>>>>> >
>>>>>>
>>>>>>
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Andreas,
hash maps should be generally O(1) while tree maps should be O(log n).
I don't think though the speed is the big issue. The thing I really
would like to improve is the testability.
I wonder if we could use just the bundle id in the maps instead of the
full bundle object. That should make it even easier to test.
Christian
On 09/28/2012 10:04 AM, Andreas Pieber wrote:
> I'm not really happy with the hash map there. Does any one know the big O
> of tree set vs hash set? Curious if the insert is really that much faster.
> Besides, right now the algorithm keeps the base order and ONLY reschedule
> bundles with a different start lvl. A hash set with only the sorting
> afterwards will destroy the base order. So rather +1 to keep the tree set.
>
> Kind regards,
> Andreas
> On Sep 28, 2012 9:45 AM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
>> I also agree that backporting the new behaviour and setting the old as
>> default makes sense.
>> I am also fine with setting the new behaviour as default on trunk. I think
>> on trunk we do not even need a switch.
>>
>> Btw. I would like to replace the TreeSet with a HashSet on trunk again as
>> we do not need the order there anymore.
>> This is probably faster and makes testing a bit simpler again.
>>
>> Christian
>>
>> On 09/28/2012 05:43 AM, Andreas Pieber wrote:
>>
>>> Hey Freeman,
>>>
>>> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com>
>>> wrote:
>>>
>>>> It's a good idea.
>>>>
>>> Thanks :-)
>>>
>>> And how about we introduce an property for FeaturesServiceImpl, and in
>>>> etc/org.apache.karaf.features.**cfg we get chance to configure this
>>>> property so that we can keep behavior as is or use the new behavior you
>>>> introduced here, just in case some user somehow still wanna use current
>>>> behavior.
>>>>
>>> Definitely +1 here; I can add this before pushing the changes. Since
>>> the change is quite limited this should be quite simple.
>>>
>>> And I suggest the default behavior is keep as is.
>>> Well, that's a point I want to discuss. I'm not sure if the current
>>> default behavior is what really meets the expectations. For example,
>>> if you give the cxf or amq feature.xml files a shot there are quite a
>>> lot of startlvl annotations for bundles. I think that it still work
>>> with the current behavior is more luck than anything else :-) In
>>> addition the new behavior will not affect most of the current
>>> applications. More over I think it's the "more sane" behavior to
>>> consider the startlvl per default and use the old one as a fallback
>>> behavior if it doesn't work out for you in any specific reason.
>>>
>>> What would make sense for me is backporting the change to 2.3 (or 2.4)
>>> and use the old behavior there per default; but for the master I think
>>> we could risk this slight change of the default behavior.
>>>
>>> Does this makes sense to you?
>>>
>>> I think the features/core/src/main/**resources/OSGI-INF/blueprint/**gshell-features.xml
>>>> need be updated accordingly.
>>>>
>>> For the new property I need to introduce you mean?
>>>
>>> My 2 cents
>>> Warmly welcomed, as always; thanks!
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> Best Regards
>>>> Freeman
>>>> －－－－－－－－－－－－－
>>>> Freeman Fang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>> Web: http://fusesource.com | http://www.redhat.com/
>>>> Twitter: freemanfang
>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>> http://blog.sina.com.cn/u/**1473905042<http://blog.sina.com.cn/u/1473905042>
>>>> weibo: http://weibo.com/u/1473905042
>>>>
>>>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>>>
>>>> Hey guys,
>>>>> First of all, just to bring everyone at the same lvl: If we install
>>>>> features all bundles in the feature(s) are installed and then started
>>>>> one after the other, in the order as they had been defined in the
>>>>> features.
>>>>>
>>>>> While in theory it should not happen there are situations where we (in
>>>>> our software) depend that those features are started at least per
>>>>> feature in the order in which they had been added. If I understand the
>>>>> CXF feature structure correctly it's also required for them. By a bug
>>>>> last week on the trunk I discovered this explicit requirement for our
>>>>> software. Starting by this discovery we've started a discussion if it
>>>>> wouldn't be better if we consider the startLvl during the feature
>>>>> startup. So, I hacked up a solution and tested it with several
>>>>> different softwares I've access to and it seamed to work pretty well.
>>>>>
>>>>> I've attached the patch to [1] and would really like to hear what you
>>>>> think about it.
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> [1] https://issues.apache.org/**jira/browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878>
>>>>>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Achim Nierbeck <bc...@googlemail.com>.
First of all I'm +1 for the new feature you just introduced, it makes
absolutely sense.
And of course only for 3.0 ;)
I'm also +1 for the treemap
regards, Achim
2012/9/28 Andreas Pieber <an...@gmail.com>:
> I'm not really happy with the hash map there. Does any one know the big O
> of tree set vs hash set? Curious if the insert is really that much faster.
> Besides, right now the algorithm keeps the base order and ONLY reschedule
> bundles with a different start lvl. A hash set with only the sorting
> afterwards will destroy the base order. So rather +1 to keep the tree set.
>
> Kind regards,
> Andreas
> On Sep 28, 2012 9:45 AM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
>> I also agree that backporting the new behaviour and setting the old as
>> default makes sense.
>> I am also fine with setting the new behaviour as default on trunk. I think
>> on trunk we do not even need a switch.
>>
>> Btw. I would like to replace the TreeSet with a HashSet on trunk again as
>> we do not need the order there anymore.
>> This is probably faster and makes testing a bit simpler again.
>>
>> Christian
>>
>> On 09/28/2012 05:43 AM, Andreas Pieber wrote:
>>
>>> Hey Freeman,
>>>
>>> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com>
>>> wrote:
>>>
>>>> It's a good idea.
>>>>
>>> Thanks :-)
>>>
>>> And how about we introduce an property for FeaturesServiceImpl, and in
>>>> etc/org.apache.karaf.features.**cfg we get chance to configure this
>>>> property so that we can keep behavior as is or use the new behavior you
>>>> introduced here, just in case some user somehow still wanna use current
>>>> behavior.
>>>>
>>> Definitely +1 here; I can add this before pushing the changes. Since
>>> the change is quite limited this should be quite simple.
>>>
>>> And I suggest the default behavior is keep as is.
>>>>
>>> Well, that's a point I want to discuss. I'm not sure if the current
>>> default behavior is what really meets the expectations. For example,
>>> if you give the cxf or amq feature.xml files a shot there are quite a
>>> lot of startlvl annotations for bundles. I think that it still work
>>> with the current behavior is more luck than anything else :-) In
>>> addition the new behavior will not affect most of the current
>>> applications. More over I think it's the "more sane" behavior to
>>> consider the startlvl per default and use the old one as a fallback
>>> behavior if it doesn't work out for you in any specific reason.
>>>
>>> What would make sense for me is backporting the change to 2.3 (or 2.4)
>>> and use the old behavior there per default; but for the master I think
>>> we could risk this slight change of the default behavior.
>>>
>>> Does this makes sense to you?
>>>
>>> I think the features/core/src/main/**resources/OSGI-INF/blueprint/**gshell-features.xml
>>>> need be updated accordingly.
>>>>
>>> For the new property I need to introduce you mean?
>>>
>>> My 2 cents
>>>>
>>> Warmly welcomed, as always; thanks!
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> Best Regards
>>>> Freeman
>>>> －－－－－－－－－－－－－
>>>> Freeman Fang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>> Web: http://fusesource.com | http://www.redhat.com/
>>>> Twitter: freemanfang
>>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>>> http://blog.sina.com.cn/u/**1473905042<http://blog.sina.com.cn/u/1473905042>
>>>> weibo: http://weibo.com/u/1473905042
>>>>
>>>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>>>
>>>> Hey guys,
>>>>>
>>>>> First of all, just to bring everyone at the same lvl: If we install
>>>>> features all bundles in the feature(s) are installed and then started
>>>>> one after the other, in the order as they had been defined in the
>>>>> features.
>>>>>
>>>>> While in theory it should not happen there are situations where we (in
>>>>> our software) depend that those features are started at least per
>>>>> feature in the order in which they had been added. If I understand the
>>>>> CXF feature structure correctly it's also required for them. By a bug
>>>>> last week on the trunk I discovered this explicit requirement for our
>>>>> software. Starting by this discovery we've started a discussion if it
>>>>> wouldn't be better if we consider the startLvl during the feature
>>>>> startup. So, I hacked up a solution and tested it with several
>>>>> different softwares I've access to and it seamed to work pretty well.
>>>>>
>>>>> I've attached the patch to [1] and would really like to hear what you
>>>>> think about it.
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> [1] https://issues.apache.org/**jira/browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878>
>>>>>
>>>>
>>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Andreas Pieber <an...@gmail.com>.
I'm not really happy with the hash map there. Does any one know the big O
of tree set vs hash set? Curious if the insert is really that much faster.
Besides, right now the algorithm keeps the base order and ONLY reschedule
bundles with a different start lvl. A hash set with only the sorting
afterwards will destroy the base order. So rather +1 to keep the tree set.
Kind regards,
Andreas
On Sep 28, 2012 9:45 AM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> I also agree that backporting the new behaviour and setting the old as
> default makes sense.
> I am also fine with setting the new behaviour as default on trunk. I think
> on trunk we do not even need a switch.
>
> Btw. I would like to replace the TreeSet with a HashSet on trunk again as
> we do not need the order there anymore.
> This is probably faster and makes testing a bit simpler again.
>
> Christian
>
> On 09/28/2012 05:43 AM, Andreas Pieber wrote:
>
>> Hey Freeman,
>>
>> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com>
>> wrote:
>>
>>> It's a good idea.
>>>
>> Thanks :-)
>>
>> And how about we introduce an property for FeaturesServiceImpl, and in
>>> etc/org.apache.karaf.features.**cfg we get chance to configure this
>>> property so that we can keep behavior as is or use the new behavior you
>>> introduced here, just in case some user somehow still wanna use current
>>> behavior.
>>>
>> Definitely +1 here; I can add this before pushing the changes. Since
>> the change is quite limited this should be quite simple.
>>
>> And I suggest the default behavior is keep as is.
>>>
>> Well, that's a point I want to discuss. I'm not sure if the current
>> default behavior is what really meets the expectations. For example,
>> if you give the cxf or amq feature.xml files a shot there are quite a
>> lot of startlvl annotations for bundles. I think that it still work
>> with the current behavior is more luck than anything else :-) In
>> addition the new behavior will not affect most of the current
>> applications. More over I think it's the "more sane" behavior to
>> consider the startlvl per default and use the old one as a fallback
>> behavior if it doesn't work out for you in any specific reason.
>>
>> What would make sense for me is backporting the change to 2.3 (or 2.4)
>> and use the old behavior there per default; but for the master I think
>> we could risk this slight change of the default behavior.
>>
>> Does this makes sense to you?
>>
>> I think the features/core/src/main/**resources/OSGI-INF/blueprint/**gshell-features.xml
>>> need be updated accordingly.
>>>
>> For the new property I need to introduce you mean?
>>
>> My 2 cents
>>>
>> Warmly welcomed, as always; thanks!
>>
>> Kind regards,
>> Andreas
>>
>> Best Regards
>>> Freeman
>>> －－－－－－－－－－－－－
>>> Freeman Fang
>>>
>>> Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>> Web: http://fusesource.com | http://www.redhat.com/
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.**com<http://freemanfang.blogspot.com>
>>> http://blog.sina.com.cn/u/**1473905042<http://blog.sina.com.cn/u/1473905042>
>>> weibo: http://weibo.com/u/1473905042
>>>
>>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>>
>>> Hey guys,
>>>>
>>>> First of all, just to bring everyone at the same lvl: If we install
>>>> features all bundles in the feature(s) are installed and then started
>>>> one after the other, in the order as they had been defined in the
>>>> features.
>>>>
>>>> While in theory it should not happen there are situations where we (in
>>>> our software) depend that those features are started at least per
>>>> feature in the order in which they had been added. If I understand the
>>>> CXF feature structure correctly it's also required for them. By a bug
>>>> last week on the trunk I discovered this explicit requirement for our
>>>> software. Starting by this discovery we've started a discussion if it
>>>> wouldn't be better if we consider the startLvl during the feature
>>>> startup. So, I hacked up a solution and tested it with several
>>>> different softwares I've access to and it seamed to work pretty well.
>>>>
>>>> I've attached the patch to [1] and would really like to hear what you
>>>> think about it.
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> [1] https://issues.apache.org/**jira/browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878>
>>>>
>>>
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Christian Schneider <ch...@die-schneider.net>.
I also agree that backporting the new behaviour and setting the old as
default makes sense.
I am also fine with setting the new behaviour as default on trunk. I
think on trunk we do not even need a switch.
Btw. I would like to replace the TreeSet with a HashSet on trunk again
as we do not need the order there anymore.
This is probably faster and makes testing a bit simpler again.
Christian
On 09/28/2012 05:43 AM, Andreas Pieber wrote:
> Hey Freeman,
>
> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com> wrote:
>> It's a good idea.
> Thanks :-)
>
>> And how about we introduce an property for FeaturesServiceImpl, and in etc/org.apache.karaf.features.cfg we get chance to configure this property so that we can keep behavior as is or use the new behavior you introduced here, just in case some user somehow still wanna use current behavior.
> Definitely +1 here; I can add this before pushing the changes. Since
> the change is quite limited this should be quite simple.
>
>> And I suggest the default behavior is keep as is.
> Well, that's a point I want to discuss. I'm not sure if the current
> default behavior is what really meets the expectations. For example,
> if you give the cxf or amq feature.xml files a shot there are quite a
> lot of startlvl annotations for bundles. I think that it still work
> with the current behavior is more luck than anything else :-) In
> addition the new behavior will not affect most of the current
> applications. More over I think it's the "more sane" behavior to
> consider the startlvl per default and use the old one as a fallback
> behavior if it doesn't work out for you in any specific reason.
>
> What would make sense for me is backporting the change to 2.3 (or 2.4)
> and use the old behavior there per default; but for the master I think
> we could risk this slight change of the default behavior.
>
> Does this makes sense to you?
>
>> I think the features/core/src/main/resources/OSGI-INF/blueprint/gshell-features.xml need be updated accordingly.
> For the new property I need to introduce you mean?
>
>> My 2 cents
> Warmly welcomed, as always; thanks!
>
> Kind regards,
> Andreas
>
>> Best Regards
>> Freeman
>> －－－－－－－－－－－－－
>> Freeman Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://fusesource.com | http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>
>>> Hey guys,
>>>
>>> First of all, just to bring everyone at the same lvl: If we install
>>> features all bundles in the feature(s) are installed and then started
>>> one after the other, in the order as they had been defined in the
>>> features.
>>>
>>> While in theory it should not happen there are situations where we (in
>>> our software) depend that those features are started at least per
>>> feature in the order in which they had been added. If I understand the
>>> CXF feature structure correctly it's also required for them. By a bug
>>> last week on the trunk I discovered this explicit requirement for our
>>> software. Starting by this discovery we've started a discussion if it
>>> wouldn't be better if we consider the startLvl during the feature
>>> startup. So, I hacked up a solution and tested it with several
>>> different softwares I've access to and it seamed to work pretty well.
>>>
>>> I've attached the patch to [1] and would really like to hear what you
>>> think about it.
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> [1] https://issues.apache.org/jira/browse/KARAF-1878
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Freeman Fang <fr...@gmail.com>.
Hi Andreas,
My comment inline
－－－－－－－－－－－－－
Freeman Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-9-28, at 上午11:43, Andreas Pieber wrote:
> Hey Freeman,
>
> On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com> wrote:
>> It's a good idea.
>
> Thanks :-)
>
>> And how about we introduce an property for FeaturesServiceImpl, and in etc/org.apache.karaf.features.cfg we get chance to configure this property so that we can keep behavior as is or use the new behavior you introduced here, just in case some user somehow still wanna use current behavior.
>
> Definitely +1 here; I can add this before pushing the changes. Since
> the change is quite limited this should be quite simple.
>
>> And I suggest the default behavior is keep as is.
>
> Well, that's a point I want to discuss. I'm not sure if the current
> default behavior is what really meets the expectations. For example,
> if you give the cxf or amq feature.xml files a shot there are quite a
> lot of startlvl annotations for bundles. I think that it still work
> with the current behavior is more luck than anything else :-) In
> addition the new behavior will not affect most of the current
> applications. More over I think it's the "more sane" behavior to
> consider the startlvl per default and use the old one as a fallback
> behavior if it doesn't work out for you in any specific reason.
>
> What would make sense for me is backporting the change to 2.3 (or 2.4)
> and use the old behavior there per default; but for the master I think
> we could risk this slight change of the default behavior.
>
> Does this makes sense to you?
Yeah, keep the new behavior as default only on trunk makes perfect sense for me.
>
>> I think the features/core/src/main/resources/OSGI-INF/blueprint/gshell-features.xml need be updated accordingly.
>
> For the new property I need to introduce you mean?
Yep
Thanks
Freeman
>
>> My 2 cents
>
> Warmly welcomed, as always; thanks!
>
> Kind regards,
> Andreas
>
>>
>> Best Regards
>> Freeman
>> －－－－－－－－－－－－－
>> Freeman Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://fusesource.com | http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> weibo: http://weibo.com/u/1473905042
>>
>> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>>
>>> Hey guys,
>>>
>>> First of all, just to bring everyone at the same lvl: If we install
>>> features all bundles in the feature(s) are installed and then started
>>> one after the other, in the order as they had been defined in the
>>> features.
>>>
>>> While in theory it should not happen there are situations where we (in
>>> our software) depend that those features are started at least per
>>> feature in the order in which they had been added. If I understand the
>>> CXF feature structure correctly it's also required for them. By a bug
>>> last week on the trunk I discovered this explicit requirement for our
>>> software. Starting by this discovery we've started a discussion if it
>>> wouldn't be better if we consider the startLvl during the feature
>>> startup. So, I hacked up a solution and tested it with several
>>> different softwares I've access to and it seamed to work pretty well.
>>>
>>> I've attached the patch to [1] and would really like to hear what you
>>> think about it.
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> [1] https://issues.apache.org/jira/browse/KARAF-1878
>>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Andreas Pieber <an...@gmail.com>.
Hey Freeman,
On Fri, Sep 28, 2012 at 4:29 AM, Freeman Fang <fr...@gmail.com> wrote:
> It's a good idea.
Thanks :-)
> And how about we introduce an property for FeaturesServiceImpl, and in etc/org.apache.karaf.features.cfg we get chance to configure this property so that we can keep behavior as is or use the new behavior you introduced here, just in case some user somehow still wanna use current behavior.
Definitely +1 here; I can add this before pushing the changes. Since
the change is quite limited this should be quite simple.
> And I suggest the default behavior is keep as is.
Well, that's a point I want to discuss. I'm not sure if the current
default behavior is what really meets the expectations. For example,
if you give the cxf or amq feature.xml files a shot there are quite a
lot of startlvl annotations for bundles. I think that it still work
with the current behavior is more luck than anything else :-) In
addition the new behavior will not affect most of the current
applications. More over I think it's the "more sane" behavior to
consider the startlvl per default and use the old one as a fallback
behavior if it doesn't work out for you in any specific reason.
What would make sense for me is backporting the change to 2.3 (or 2.4)
and use the old behavior there per default; but for the master I think
we could risk this slight change of the default behavior.
Does this makes sense to you?
> I think the features/core/src/main/resources/OSGI-INF/blueprint/gshell-features.xml need be updated accordingly.
For the new property I need to introduce you mean?
> My 2 cents
Warmly welcomed, as always; thanks!
Kind regards,
Andreas
>
> Best Regards
> Freeman
> －－－－－－－－－－－－－
> Freeman Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: http://weibo.com/u/1473905042
>
> On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
>
>> Hey guys,
>>
>> First of all, just to bring everyone at the same lvl: If we install
>> features all bundles in the feature(s) are installed and then started
>> one after the other, in the order as they had been defined in the
>> features.
>>
>> While in theory it should not happen there are situations where we (in
>> our software) depend that those features are started at least per
>> feature in the order in which they had been added. If I understand the
>> CXF feature structure correctly it's also required for them. By a bug
>> last week on the trunk I discovered this explicit requirement for our
>> software. Starting by this discovery we've started a discussion if it
>> wouldn't be better if we consider the startLvl during the feature
>> startup. So, I hacked up a solution and tested it with several
>> different softwares I've access to and it seamed to work pretty well.
>>
>> I've attached the patch to [1] and would really like to hear what you
>> think about it.
>>
>> Kind regards,
>> Andreas
>>
>> [1] https://issues.apache.org/jira/browse/KARAF-1878
>
Re: Feature Service PHYSIKOdata bundle startup order
Posted by Freeman Fang <fr...@gmail.com>.
Hi Andreas,
It's a good idea.
And how about we introduce an property for FeaturesServiceImpl, and in etc/org.apache.karaf.features.cfg we get chance to configure this property so that we can keep behavior as is or use the new behavior you introduced here, just in case some user somehow still wanna use current behavior.
And I suggest the default behavior is keep as is.
I think the features/core/src/main/resources/OSGI-INF/blueprint/gshell-features.xml need be updated accordingly.
My 2 cents
Best Regards
Freeman
－－－－－－－－－－－－－
Freeman Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042
On 2012-9-28, at 上午12:58, Andreas Pieber wrote:
> Hey guys,
>
> First of all, just to bring everyone at the same lvl: If we install
> features all bundles in the feature(s) are installed and then started
> one after the other, in the order as they had been defined in the
> features.
>
> While in theory it should not happen there are situations where we (in
> our software) depend that those features are started at least per
> feature in the order in which they had been added. If I understand the
> CXF feature structure correctly it's also required for them. By a bug
> last week on the trunk I discovered this explicit requirement for our
> software. Starting by this discovery we've started a discussion if it
> wouldn't be better if we consider the startLvl during the feature
> startup. So, I hacked up a solution and tested it with several
> different softwares I've access to and it seamed to work pretty well.
>
> I've attached the patch to [1] and would really like to hear what you
> think about it.
>
> Kind regards,
> Andreas
>
> [1] https://issues.apache.org/jira/browse/KARAF-1878