kk I'll create a (very) small example (and if there is really a problem) create an issue with the demo attached
Kind regards, Andreas On Fri, Mar 4, 2011 at 10:23 AM, Guillaume Nodet <[email protected]> wrote: > 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 >
