Although I would rather prefer an opt-out approach I can also live with opt-in (with a blacklist and ldap syntax) --> +1
Kind regards, Andreas On Mon, May 30, 2011 at 7:44 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Mike, > > it's another point of view. We can mix the Guillaume and your remarks: > > 1/ avoid to include an autostart attribute in the features descriptor and > prefer the usage of features.blacklist property in > etc/org.apache.karaf.features.cfg file. This property defines the features > (feature name or feature name/version separated by a comma) which won't be > started/installed automatically > 2/ by default, install/start all features contained in a features > descriptor. > > We just need to be careful with large features descriptor such as the Camel > one. The features.blacklist property should support LDAP filter format to > define the blacklisted features (for instance > (&(!name=camel-core)(name=camel-*) to start/install only the camel-core > feature). WDYT ? > > Regards > JB > > On 05/29/2011 10:36 PM, mikevan wrote: >> >> -1 (non-binding) >> >> It has always appeared strange to me that features:addUrl didn't work the >> same way as dropping a features.xml into the deploy directory. >> >> In practice, dropping a features.xml file into the deploy directory >> currently deploys all of the features listed in that file. The rub >> appears >> to be that this is not the default behaviour when using features:addUrl to >> add a features repository. I like the idea of this when using the >> features:addUrl command, however my question is what would this do to the >> default behaviour of the deploy directory? Would we have an "autostart= >> false" for features we dont' want to start when adding a features >> repository >> via the deploy directory? >> >> Instead, I propose the following: >> 1) change the features:addUrl behaviour to match the behaviour we see when >> adding a features file to the deploy directory, basically this would >> remove >> the need for an autostart=true capability as all features would be started >> automatically unless otherwise noted, and >> 2) add an "autostart=false" attribute to the features.xml xsd that would >> keep the feature from being deployed. >> >> >> >> jb-3 wrote: >>> >>> Hi all, >>> >>> What do you think about adding an autostart attribute on the features >>> element ? >>> >>> The purpose is to be able to have something like: >>> >>> <feature name="myfeature" version="1.0-SNAPSHOT" autostart="true"> >>> ... >>> </feature> >>> >>> When an user register a features descriptor (using features:addurl), >>> deploy a KAR containing a features descriptor or drop a features >>> descriptor in the deploy folder, Karaf will try to automatically start >>> the >>> features with autostart flag set to true. >>> >>> It will avoid users to: >>> - start by hand features contained in a KAR: the user can drop the KAR >>> into the deploy folder, but he must connect to Karaf and start the >>> features by hand >>> - start by hand features after an addurl when the user "controls" the >>> features content >>> >>> Thoughts ? >>> >>> Regards >>> JB >>> >> >> >> ----- >> Mike Van (aka karafman) >> Karaf Team (Contributor) >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/PROPOSAL-Features-autostart-attribute-tp2992236p2999943.html >> Sent from the Karaf - Dev mailing list archive at Nabble.com. >
