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 >
