Hi Christian,
Starting with the hypothesis that your features descriptor looks like:
<features>
<feature name="my" version="1.0">
<feature>camel</feature>
<feature>camel-stream</feature>
<bundle>mvn:my/my-bundle/1.0</bundle>
</feature>
<feature name="my.optional" version="1.0">
<feature>my</feature>
<bundle>mvn:my/my-optional/1.0</bundle>
</feature>
</features>
you could expect that your "my" feature will be automatically
installed/started as soon as you register the URL, but not my.optional.
The purpose of the -s option with the LDAP filter is to be able to
automatically start a set of features.
Regards
JB
On 05/31/2011 10:16 PM, Christian Schneider wrote:
Sounds better to me than other options but I wonder if we really need
this at all.
When I deploy a camel app then I create a feature file for it with one
feature that that references all camel features it needs. So I would
intall the camel feature file without starting any features. Then I
would install the feature file of my app and there all of the features
in the file (typically only one) could be auto started. So in my
practice I never needed to start some features. I always either wanted
to start all or no features.
Christian
Am 31.05.2011 09:40, schrieb Jean-Baptiste Onofré:
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.
