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