karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: Feature Service PHYSIKOdata bundle startup order
Date Sat, 29 Sep 2012 03:19:08 GMT

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
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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message