The features services isn't aware of blueprint so that should not be the case. To double check, create a bundle with a bean sleeping for a while in the init method. It should not delay other features.
On Fri, Mar 4, 2011 at 10:16, Andreas Pieber <[email protected]> wrote: > I'm not sure but I see the following behavior: > > features.cfg: A,B > > FeatureAbundleX Started Blueprint Started > FeatureAbundleY Started Blueprint Grace > FeatureBbundleZ Resolved > > Then you wait till FeatureABundleY sets to Blueprint Started and only > then FeatureBbundleZ is set to Started and this is not necessary IMHO > > Kind regards, > Andreas > > On Fri, Mar 4, 2011 at 9:49 AM, Guillaume Nodet <[email protected]> wrote: >> Blueprint does start asynchronously, so if most of your bundles are >> blueprint powered, it should already happen. >> Do I miss something here? >> >> On Fri, Mar 4, 2011 at 05:18, Andreas Pieber <[email protected]> wrote: >>> OK, another feature proposal for 3.0: >>> >>> I've the following "problem" with the OpenEngSB project right now. We >>> have different features where some are optional, but if they are >>> defined they could also start in parallel. E.g. assume you have >>> feature A and feature B. Feature A requires some time to come up since >>> it requires some time to get all blueprint services wired, BUT feature >>> B does not need to wait till feature A is finished but could rather >>> startup with feature A (as if they're defined in the same feature). >>> >>> I can think of two solutions for the problem >>> >>> 1) Define parallel startup in features.cfg. In Archlinux you have a >>> Daemons array defined saying which services to start during the boot >>> which looks something like: >>> >>> DAEMONS=(syslog-ng netfs crond dbus !network wicd @acpid @cups @ntpdate >>> @mpd) >>> >>> This means now: first start syslo.. then netfs, then crond (one after >>> the other, similar to our feature file), but you don't have to wait >>> for acpid, cups, ntpdate to wait, start them up and go ahead (thats >>> what the @means). >>> >>> I can think of the same for Karaf: >>> >>> A,@B >>> >>> which could mean: start feature A and feature B like they where the same >>> feature >>> >>> 2) A different solution could be to add a new tag to the features.xml >>> listing the features with which a feature could be started in parallel >>> ---> >>> >>> Feature B could contain: >>> >>> <couldBeStartedTogetherWith><feature version...>A</feature><feature >>> version...>OTHER_FEATURE</feature></couldBeStartedTogetherWith> >>> >>> ------------ >>> I think it may be good to support borth options since the feature >>> developer should now best with which features his feature could start >>> in parallel, BUT the feature developer can not imagine each possible >>> feature which could be started in parallel with his feature. >>> >>> So, WDYT? :) >>> >>> Kind regards, >>> Andreas >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
