Hi JB, I understand your concern, especially with the camel features file which is the biggest I know of right now :-) Never the less I think this should be a straight forward approach and transparent for the user. So if we decide to constrain this behavior it should be done through the command. So something like
features:addUrl -s (ldap filter) - to only start the features matching and features:addUrl -s - to start all features inside the features file I think this gives the user the right amount of control while doing exactly what he wants. If we think of a external file to alter, it won't be as transparent. I like to go for a KISS approach :-) regards, Achim 2011/5/31 Jean-Baptiste Onofré <[email protected]>: > Hi Achim, > > my only concern with -s option is that it will start all features in the > features descriptor. > > For instance: > > features:addUrl -s > mvn:org.apache.camel.karaf/apache-camel/2.7.1/xml/features > > will install all features in the Camel features descriptor whereas the users > expect 3 or 4 depending of their routes. > > That's why the start behavior should be define by feature. I'm agree with > the Guillaume comments about avoid to define this on the feature itself. The > autostart property (using regexp/LDAP filter) allows to control this > behavior feature by feature. > > Regards > JB > > On 05/31/2011 09:02 AM, Achim Nierbeck wrote: >> >> Hi JB, >> >> picking up your two ideas, >> >> for 1 I'd rather would expect something like features:addUrl -s like >> with the osgi:install that it should start all features within the >> features url >> this way we are more consistent and I think it gives the user the >> needed control. >> for 2 I agree since is actually the behavior I would have expected anyways >> :-) >> >> regards, Achim >> >> 2011/5/31 Jean-Baptiste Onofré<[email protected]>: >>> >>> Hi Christian, >>> >>> I'm fully agree with you and it's my first concern when you read my >>> previous >>> e-mail of the thread. >>> >>> I prefer: >>> 1/ add a autostart property in the etc/org.apache.karaf.features.cfg file >>> to >>> features installed from the command line. It allow people to >>> automatically >>> start the features that he wants. >>> 2/ enhance the deployer (kar and features) to automatically start the >>> features dropped in the deploy folder >>> >>> Regards >>> JB >>> >>> On 05/30/2011 08:05 PM, Christian Schneider wrote: >>>> >>>> Hi JB, >>>> >>>> I don´t think autostart makes sense as a default. For example take the >>>> camel feature file. You would probably never want to start all the >>>> features. Blacklisting all that should not be started also seems like a >>>> bad idea as in the camel case that would be just too many. >>>> >>>> I like the current way it works. features:addurl only installs the file >>>> and in a scond step you start the features you need. An option on addUrl >>>> could start all the features in the file if this is wanted. >>>> >>>> For features dropped into the deploy dir the dir should give the >>>> default. So if the default is to start bundles dropped into that dir >>>> then features should also be started. Kars should then behave in the >>>> same way. >>>> >>>> Christian >>>> >>>> >>>> Am 30.05.2011 07:44, schrieb Jean-Baptiste Onofré: >>>>> >>>>> 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. >>>>> >>>> >>> >> >> >> > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
