Yes, currently, using features, we do feature:uninstall && feature:install.
It means that the feature are uninstall (at least on one instance, using
multiple instances configuration, we can be only in a degraded mode).
Regards
JB
On 06/12/2012 05:23 PM, James Carman wrote:
On Tue, Jun 12, 2012 at 10:47 AM, Christian Schneider
<[email protected]> wrote:
I typically just use a normal feature file to describe my application to be
deployed.
That's what we're doing now.
At runtime I log into the console, add the feature file and install the
needed features. There is no need to
add the features to the boot features as karaf will remember the running
bundles anyway.
The reason we went with boot features is we were having troubles
getting stuff to start up correctly with karaf commands. I have a
feeling that blueprint will solve this without the need to use boot
features, so I'm anxious to try it out!
An update is a little complicated at the moment as you have to uninstall the
features, uninstall the feature
file and then do the above. We are already working on better ways to do this
though.
Basically the idea is to have an update command where you just give the new
version and karaf does the update.
That's what I'm thinking, but I just wanted to understand what all of
you experts were doing. When doing this, does it end up bringing
everything down anyway? Or is that all part of strategically crafting
your bundles so that they can go up/down independently of one another?
You can install default configs and config files with your feature and then
configure them using the files or the config admin service (jmx, webconsole,
..).
How do you install default configs when using the features plugin? We
really like using the plugin because it automatically takes care of
the correct versions for you. I could go back to hand-writing it,
but what a pain!
For DB and JMS it is a good practice to use services for the DataSource or
ConnectionFactory. See
http://www.liquid-reality.de/x/LYBk . This way you can really let the admins
do these configs. Your app only knows about a named DataSource.
We're somewhat doing this. I've set up a blueprint file that
basically defines all of the connections we need. In it, it has
properties that the admins can set to override the default settings
(like pool sizes, etc.). We deploy this blueprint file as a "feature"
in our features repository and our admins just have to make sure they
set all the correct properties.
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
