karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: Feature Service PHYSIKOdata bundle startup order
Date Fri, 28 Sep 2012 03:57:16 GMT
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.fang@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
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message