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" <ch...@die-schneider.net> wrote: > Hi Andreas, > > hash maps should be generally O(1) while tree maps should be O(log n). > I don't think though the speed is the big issue. The thing I really would > like to improve is the testability. > > I wonder if we could use just the bundle id in the maps instead of the > full bundle object. That should make it even easier to test. > > Christian > > On 09/28/2012 10:04 AM, Andreas Pieber wrote: > >> 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://freemanfang.blogspot.com>> >>>>> http://blog.sina.com.cn/u/****1473905042<http://blog.sina.com.cn/u/**1473905042> >>>>> <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> >>>>>> <https:/**/issues.apache.org/jira/**browse/KARAF-1878<https://issues.apache.org/jira/browse/KARAF-1878> >>>>>> > >>>>>> >>>>>> >
