That's exactly what is supposed to happen because we use the org.apache.felix.utils.properties.Properties which is known to work for that. One thing that could happen though is that the properties that are substituted are not know to fileinstall, so that it can't really compare the real values. The reason is that file install doesn't use the bundle system context when computing the substitution so it only takes into account the substitution within the file, not with system properties or bundle context properties. I'm actually not sure who does such a substitution on the client side as I doubt ConfigAdmin does not automatically.
On Wed, Apr 25, 2012 at 11:11, Bengt Rodehav <[email protected]> wrote: > One improvement I've been thinking about is to only write back properties > that have actually changed. This would help in my case since I have my own > web gui that disables/enables my services. I do so by setting an iPOJO > @Controller property to true/false via config admin. I therefore don't use > any variables for this particular property but my other configuration > properties (that are not changed) are "ruined" because of the variable > expansion. > > I'm not sure if config admin provides enough information to determine what > properties have been changed. Either way file install could probably > evaluate it's current value of the property (and do variable expansion in > the process) and compare this value with the value provided by config > admin. If they are the same than no writing back of this property is needed > and the variable would then be preserved in the configuration file. > > I guess it would also be possible to preserve variables in properties that > have been changed as well. File install could check if the original value > contained variables. It could then try use those variables for the new > value as well. It would then have to search in the new value if the value > of the property is still used and then substitute that value for the > property. This is not foolproof and could be ambiguous but I think it could > be implemented to work in most cases. This feature should be configurable > since it is not 100% safe. > > The feature not to write back properties that have not changed could also > be configurable but doesn't really have to be since I believe it can be > made foolprooof. > > /Bengt > > 2012/4/25 Bengt Rodehav <[email protected]> > > > I use file install (currently 3.1.10 but have also tried with 3.2.2) in > > Karaf 2.2.5 to feed configurations (both normal and factory > configurations) > > into the config admin service. > > > > In my configuration files I use different variables that I define in > > Karaf's custom.properties file. I'm not sure whether Karaf exposes them > as > > system properties but they are nevertheless picked up by fileinstall. > > > > However, when fileinstall is configured to write back configuration > > changes to the configuration file, these variables are not preserved but > > are expanded. This makes it very hard to read and further maintain the > > configuration files. I can easily see why this is happening since the > work > > is divided between file install and the configuration admin and the > latter > > does not know about the variables at all. > > > > I don't have a suggestion how to solve this but this is a major problem > > (for me at least) to use fileinstall and config admin together. I guess > if > > fileinstall was just an implementation of the config admin instead of a > > general listener to configuration chagnes there would be other > > possibilities. > > > > Does anyone have any suggestions how to combine write back of > > configuration changes with preservation of variables? Could fileinstall > > provide such a feature? > > > > /Bengt > > > > > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
