First of all I'm +1 for the new feature you just introduced, it makes absolutely sense. And of course only for 3.0 ;)
I'm also +1 for the treemap regards, Achim 2012/9/28 Andreas Pieber <anpie...@gmail.com>: > 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> >>>>> >>>> >> -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
