karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [PROPOSAL] Features autostart attribute
Date Tue, 31 May 2011 07:33:24 GMT
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é <jb@nanthrax.net>:
> 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é<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
>>>>>>> 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

Mime
View raw message