You mean that only properties that have changed should be written back? Not the part where variables are preserved even in changed properties - I assume.
At a first glance I can't figure out where the variable substitution takes place either. But for this to work, it must be done before comparing with the existing value - right? /Bengt 2012/4/25 Guillaume Nodet <[email protected]> > 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 >
