Good idea Achim,
+1 to provide -s option with LDAP filter support.
Regards
JB
On 05/31/2011 09:33 AM, 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.
