karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Features autostart attribute
Date Tue, 31 May 2011 07:24:22 GMT
Hi Achim,

my only concern with -s option is that it will start all features in the 
features descriptor.

For instance:

features:addUrl -s 

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.


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é<jb@nanthrax.net>:
>> 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
>>>>>> 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"
>>>>>> 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.

View raw message