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