felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Provide an option to persist a config to a file in e.g. etc
Date Mon, 17 Sep 2012 11:46:12 GMT
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)
- 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)
  2. The config was created in config admin service. In this case no 
additional write happens
So it is very well possible that the implementation of the "etc" 
peristence came from fileinstall.

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 
I think the creation of new files should be done in the same module that 
currently implements the write to the etc files.


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 
>> <chris@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

Open Source Architect
Talend Application Integration Division http://www.talend.com

View raw message