Achim, I like this. If I understand this correctly, the default behavior would be that none of the features in features repository would be started unless -s is in place, right?
Achim Nierbeck wrote: > > 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 > ----- Mike Van (aka karafman) Karaf Team (Contributor) -- View this message in context: http://karaf.922171.n3.nabble.com/PROPOSAL-Features-autostart-attribute-tp2992236p3008041.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
