Ideas for config admin with factories

2014-01-13 Thread Christian Schneider

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

2014-01-13 Thread Jean-Baptiste Onofré

+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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Ideas for config admin with factories

2014-01-13 Thread Christian Schneider
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

2014-01-13 Thread Jean-Baptiste Onofré

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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com