Hello again Guillaume, I found the place where the substitution is being made. It's in the class InterpolationHelper which resides in the same package as Felix Properties class.
I made a small test. It seems like variables defined as system variables are preserved (because InterpolationHelper knows about them). Also, if I refer to other configuration properties, they are preserved as well. However, the properties I define in my custom.properties file are not preserved. Apparently they are not substituted by InterpolationHelper. I have no idea where that substitution takes place but I would like to make fileinstall aware of it. Do you think that is possible? /Bengt 2012/4/25 Guillaume Nodet <[email protected]> > 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 >
