karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Ideas for config admin with factories
Date Mon, 13 Jan 2014 13:08:12 GMT
+1 for me.

Maybe the support of regex in config:edit can help too (to be able to 
find the first occurrence of a config matching a regexp).


On 01/13/2014 01:55 PM, Christian Schneider wrote:
> Hi all,
> I have been working on https://issues.apache.org/jira/browse/KARAF-2676 .
> The problem described in the issue is that you can not edit factory
> based configs using their file name like you might expect as a user.
> I first thought this should be solveable easily but the core problem is
> deep in the config admin spec.
> Spec side:
> The spec handles factory based configs very differently from normal
> configs. For a normal config you have a user defined pid that you know
> in advance. We make use of this in the config:edit command where we
> specify a fixed pid and save this later in the conig:update command. For
> factory based configs the spec defines that you create such a config
> using createFactoryConfiguration with the factory pid as the parameter.
> The real pid is then named <factoryPid>.<generated id>. So there is no
> way to know this id beforehand.
> Felix config admin side:
> When reading a factory based config from etc felix config admin suports
> a file name scheme <factorypid>-<id>. So if felix config admin finds
> such a file it creates a config. The config pid does not match the
> scheme given though. It will always have a generated id. So it is
> difficult find it later.
> Karaf side:
> Currently we support creating a factory config in the update command if
> the pid defined in config:edit is like <factoryPid>-<any string>. The
> problem is that the string after the hyphen can not be given to config
> admin service. So the created config always looks like
> <factoryPid>.<generated id>. Felix config admin will also not be able to
> create a file for this config.
> Idea:
> So my idea is to do two things. In config:edit I would add an option
> --factory. If it is set then the pid given is treated as a factory pid.
> The edit then starts with an empty config and on config:update a new
> factory config is created and the pid is returned.
> I also would like to print if config:edit is called for a non existent
> config. Like:
> "No config present with pid=<pid>. Creating new config on update."
> The idea behind this is to make it more obvious for users that intend to
> edit an existing config that they are not hitting the correct config.
> For the jira issue in the start this would have helped immensely to see
> what it going wrong.
> What do you think?
> Christian

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message