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.
