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 <freeman.f...@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>
>>>>
>>>
>

Reply via email to