Totally agree with all points here.
Freeman
On 2011-5-31, at 上午2:05, 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.
---------------------------------------------
Freeman Fang
FuseSource
Email:[email protected]
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
