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