Hello Jean-Baptiste, Thanks for the answers. Some more clarifications below:
> Yes <config/> and <configfile/> are both supported in Karaf 2.2.x (we > already use it in Karaf itself, Cellar, etc). However, you should be > able to see the config (using config:list > "(service.pid=com.foo.bar-alias)") but not the config file in etc. To > have a config file in etc, you should use <configfile/> in the feature > (as Cellar does). OK, after multiple changes (some things needed, some things not - including installing felix scr before installing the webconsole), I do now see the configuration in the webconsole. Unfortunately I hit this outstanding cellar issue: https://issues.apache.org/jira/browse/KARAF-1492 So once I removed cellar I could get my application to read the configuration. A question - Would it be possible to not closely tie the hazelcast instance service so closely to cellar? It has value even without bringing in the rest of cellar. I created my own hazelcast service bundle for now to get around this. >> The advantage of doing it this way is that you can be sure all optional >> dependencies/fragments are resolved before starting any bundle (thus you >> don't have to worry about ordering the bundles). I have a patch...and I >> will >> open a JIRA unless someone thinks this is foolish. This solves for me >> problems with getting fragments resolved (which are started after their >> bundle hosts) > I gonna check that, it's "weird" as we already use fragment in features > without problem. How often you see this will depend on whether you use felix or equinox (perhaps equinox starts bundles more quickly?), though I haven't tested with felix recently because the 3.x version had problems which looked like they wouldn't be corrected until 4.x. In my specific case I had about 18 bundles + 3 fragments (some brought in via obr) started in one feature. There are other niggling timing issues with features I have as well. For example, say you define your featureBoot like this: featuresBoot=config,ssh,management,obr,kar,war,<feature that depends on obr resolution> The "feature that depends on obr resolution" may not install correctly because obr may not have finished starting before attempting to install the "obr dependent feature". Perhaps there is no reasonable solution to a timing issue like this (it would be really nice if you could somehow make sure a previous feature is started before attempting to install the next one)...but it makes it harder to setup an automated install. >> <tarfile >> directory="/etc/myconfigfolder">mvn:com.mycompany/myproject/1.0.0/tar.gz/myconfig</configfile> >> >> >> Is this a reasonable idea? > > Why not, even if it should be the responsability of a provisioning > layer, like Kalumet for instance. > Kalumet is able to manage config files (for instance) coming from any > kind of VFS (http:tar, zip, bzip2, cifs, etc). OK, thanks! I will add a feature request then. I see a lot of good work being done with projects like Apache ACE and newer projects like Kalumet. I will keep an eye on them. Thanks very much again for the answers! Gareth -- View this message in context: http://karaf.922171.n3.nabble.com/More-Questions-Mostly-On-Features-tp4025892p4025910.html Sent from the Karaf - User mailing list archive at Nabble.com.
