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.
