karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: Feature Service PHYSIKOdata bundle startup order
Date Fri, 05 Oct 2012 10:35:40 GMT
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,

[1] https://issues.apache.org/jira/browse/KARAF-1878

On Sat, Sep 29, 2012 at 5:19 AM, Freeman Fang <freeman.fang@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" <chris@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" <chris@die-schneider.net>
>>>> wrote:

View raw message