Yes, only properties that have change should be written back. But as you said, the check is done by substituting inside the properties file, but if the computed value is different from the value from the configuration, the whole property will be overwritten by the new value. Do you have substitution with system properties or other bundle configuration properties ? If so, those properties will be overwritten at the first change.
On Wed, Apr 25, 2012 at 12:28, Bengt Rodehav <[email protected]> wrote: > 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 > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
