Hi Felix,
thanks for the explanations.
Do you think it is ok to add the functionality to create config files
for existing config pids to fileinstall?
If yes do you have any preference how to do it? I think we have the
option of a special config pid property or a service API.
The property would have the advantage that it would just be ignored by
other implementations. So of course we would depend on felix fileinstall
for the functionality but a user could still
exchange the config admin service and fileinstall and only loose this
one functionality.
If you generally aprove the idea of the feature I propose I will create
a jira issue and work on a patch. Is that ok?
Christian
Am 17.09.2012 13:55, schrieb Felix Meschberger:
Hi,
Am 17.09.2012 um 13:46 schrieb Christian Schneider:
Actually I am not exactly sure where which behaviour is implemented. I
will dig into it though.
What I can see from the outside when using felix fileinstall and config
admin service together is the following:
- If I have config in etc which is monitored by fileinstall then each
.cfg file causes a config pid to be created. It also monitors for
changes and reflects them in the config pids. (This is probably all done
by fileinstall)
correct
- When I change a config pid with config admin service there are two cases:
1. The config originated in a file from etc. In this case changes are
persisted back to the original file (I think this happens additional to
the internal persistence of config admin service)
correct because File Install adds a property indicating the original file from
where the configuration was created.
2. The config was created in config admin service. In this case no
additional write happens
Since Fileinstall does not know this configuration and does not have the file
name property it probably just ignores it.
So it is very well possible that the implementation of the "etc"
peristence came from fileinstall.
yes.
So about the creation of new files for existing pids:
I understand that doing this in config admin service directly may not be
the right place. So perhaps this is a theme for fileinstall? I know that
we could also do the initial creation in the karaf code but then we have
another place where we fiddle with persistence. This is why I ask this
here.
I think the creation of new files should be done in the same module that
currently implements the write to the etc files.
I would think file install might pick up new config from config admin and write
it back.
Remember, though: The canonical source for configuration is always
Configuration Admin. The on-filesystem copy that Fileinstall manages is just an
administrator's helper.
Regards
Felix
Christian
Am 17.09.2012 12:47, schrieb Jean-Baptiste Onofré:
I think that Christian is talking about the behavior inside Karaf
where we mix FileInstall and ConfigAdmin.
Regards
JB
On 09/17/2012 12:45 PM, Marcel Offermans wrote:
On Sep 17, 2012, at 11:47 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
felix config admin behaves differently if the config originated from
a file or was directly created in config admin. For most cases this
is good.
Maybe I missed something, but how does the Felix implementation of
ConfigAdmin behave differently? As far as I'm aware, the ConfigAdmin
spec says nothing at all about where a configuration originated from
(a file or whatever).
Greetings, Marcel
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
