[
https://issues.apache.org/jira/browse/KARAF-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869609#comment-13869609
]
Christian Schneider commented on KARAF-2676:
--------------------------------------------
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.
> Editing properties in configuration files managed via MangedServiceFactories
> leads to corrupt property file
> -----------------------------------------------------------------------------------------------------------
>
> Key: KARAF-2676
> URL: https://issues.apache.org/jira/browse/KARAF-2676
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-config
> Affects Versions: 2.3.3, 3.0.0
> Environment: Windows 7
> Reporter: Achim Finke
> Assignee: Christian Schneider
> Attachments: ConfigManagedServiceFactoryTest.java
>
>
> Editing a property of a configuration file managed by ManagedServiceFactory
> has the effect that any other properties in the file are lost.
> Take a look at the attached JUnit-Test for details.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
