Hi Andreas, My comment inline －－－－－－－－－－－－－ 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://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042 On 2012-9-28, at 上午11:43, 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? Yeah, keep the new behavior as default only on trunk makes perfect sense for me. > >> 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? Yep Thanks Freeman > >> 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://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 >>
