You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/01/13 13:55:11 UTC
Ideas for config admin with factories
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for config admin with factories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, good idea.
Regards
JB
On 01/13/2014 02:27 PM, Christian Schneider wrote:
> Alternatively we could support an ldap filter for edit like we already
> do for list. If the ldap query matches exactly one config we could edit it.
>
> Christian
>
>
> On 13.01.2014 14:08, Jean-Baptiste Onofré wrote:
>> +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).
>>
>> Regards
>> JB
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Ideas for config admin with factories
Posted by Christian Schneider <ch...@die-schneider.net>.
Alternatively we could support an ldap filter for edit like we already
do for list. If the ldap query matches exactly one config we could edit it.
Christian
On 13.01.2014 14:08, Jean-Baptiste Onofré wrote:
> +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).
>
> Regards
> JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for config admin with factories
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+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).
Regards
JB
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com