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, 28 Sep 2012 15:42:36 GMT
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,
On Sep 28, 2012 11:52 AM, "Christian Schneider" <chris@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" <chris@die-schneider.net>
>> wrote:

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