Use config admin to configure more karaf services? How about DS?

[David Jencks <da...@yahoo.com>]

I was a bit surprised to realize that the etc/*.cfg files are all for blueprint property file configuration and don't have anything to do with config admin.  I was also mildly surprised to find that config admin settings are all in the config admin data area so they are wiped out by a clean start.

I think at least some karaf services would be easier to set up and configure using DS, the metatype service, and config admin than with blueprint: the features service looked especially good for this approach.

I'd like to suggest keeping the config admin data under etc/conf, possibly adding an additional clean option to clean this too, and converting at least "easy" karaf services to use config admin possibly through DS.

I personally haven't gotten the aries blueprint config admin namespace handler to work, nor does it seem to me to have good semantics for property change, nor is it standardized, so I'm biased towards DS.  If blueprint + config admin works and there's a good reason to use it I don't have a problem with it.

thoughts?

thanks
david jencks

Re: Use config admin to configure more karaf services? How about DS?

[Guillaume Nodet <gn...@gmail.com>]

Nearly all those files are used for ConfigAdmin.   There is maybe one
exception, but that's all.
Those files are loaded by fileinstall and given to config admin.   The
configuration are then used by blueprint.

For example:
  http://svn.apache.org/repos/asf/karaf/trunk/assemblies/apache-karaf/src/main/distribution/text/etc/org.apache.karaf.shell.cfg
is used by:
  http://svn.apache.org/repos/asf/karaf/trunk/shell/ssh/src/main/resources/OSGI-INF/blueprint/shell-ssh.xml
See the cm:property-placeholder in the above file.

Not sure what you mean with DS.  DS is similar to BLueprint and both
can use ConfigAdmin.
The Blueprint ConfigAdmin is used in most of the bundles already.
Changes are really coarse grained and it usually end up with the
blueprint applicaton to be recreated, but I think that makes the
underlying beans really easy to write anyway, so not sure there's a
real problem here (though I'm happy to discuss that).

On Sun, Apr 17, 2011 at 21:07, David Jencks <da...@yahoo.com> wrote:
> I was a bit surprised to realize that the etc/*.cfg files are all for blueprint property file configuration and don't have anything to do with config admin.  I was also mildly surprised to find that config admin settings are all in the config admin data area so they are wiped out by a clean start.
>
> I think at least some karaf services would be easier to set up and configure using DS, the metatype service, and config admin than with blueprint: the features service looked especially good for this approach.
>
> I'd like to suggest keeping the config admin data under etc/conf, possibly adding an additional clean option to clean this too, and converting at least "easy" karaf services to use config admin possibly through DS.
>
> I personally haven't gotten the aries blueprint config admin namespace handler to work, nor does it seem to me to have good semantics for property change, nor is it standardized, so I'm biased towards DS.  If blueprint + config admin works and there's a good reason to use it I don't have a problem with it.
>
> thoughts?
>
> thanks
> david jencks
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/