Hi Uwe,
first of all, thanks for using Karaf and sharing your experience ;)
See my comments inline:
1. The ability to "install" a configuration is a great thing, but currently
only new configurations are installed. So if a configuration for a given PID
exists, it isn't touched.
For us it would be very helpful to be able to extend an existing
configuration by merging the new properties of a config-feature to the
existing configuration.
For example:
The initial configuration looked like:
<feature name="config-feature" version="1.0">
<config name="sample.conf">
prop1=value1
</config>
</feature>
The updated configuration could be:
<feature name="config-feature" version="1.1">
<config name="sample.conf">
prop1=value1
prop2=value2
</config>
</feature>
So if you install config-feature/1.0, uninstall it and install
config-feature/1.1, prop2 will not be set/initialized in CM, since
"sample.conf" is existing.
It would be very nice if the config-installer would be able to process the
existing configuration and at least adds properties that are not existing.
Possibly the behaviour of the config-installer could be influenced by an
extension to the "config"-tag. Something like
<config name="sample.conf" mergeconf="yes/no/overwrite">
would even allow the complete overwriting of an existing configuration.
A similar behavior exists if you use <configfile/> instead of <config/>.
With <configfile/>, if the final configuration file already exists, you
can set an attribute to override existing configuration.
Regarding the <config/> tag, it makes sense to have something similar.
If overwrite is easy to do, merge could be tricky.
Anyway, I'm gonna raise the Jira for that, as it could be an interesting
and logic enhancements for Karaf 3.0.
2. The feature-definitions open the ability to "chain" to installation of
features by defining dependend features. So you could install a "main"
feature that includes all features you need to run your application. If you
install "main" all the defined and needed features are installed
(recursively).
But when you uninstall the "main" feature, all other features (referenced in
"main") aren't touched and are kept installed and each of them has to
uninstalled "by hand".
True, it's the expected behavior as a dependent feature could be
installed "outside" the main feature.
So an extension like "features:uninstall -r main" would be helpful that
uninstalls all dependend features recursively just like "features:install"
does for installing features.
I am aware of the fact that this not exactly the way features should be used
and that it is much more complex than described (look up features already
installed, etc.), but such an extension would make life much more easier.
The -r (as recursive) option could be interesting on a feature. I'm OK
to be an option, and raise a warning to the user that use it, as it
could be very very dangerous ;)
Regards
JB
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
