Wouldn't that be a neat feature? Shall I create a JIRA? /Bengt
2012/4/25 Guillaume Nodet <[email protected]> > You're absolutely right. Custom properties are loaded by karaf main and > given to the system bundle when the osgi framework is created, which are > then made available to all bundles using BundleContext#getProperty(). > The InterpolationHelper can be given a BundleContext which can be used in > exactly the way we want. > > On Wed, Apr 25, 2012 at 13:47, Bengt Rodehav <[email protected]> wrote: > > > The way I understood it, the InterpolationHelper is not used by config > > admin but when the configuration is loaded from file (which is initiated > by > > file install). Thus, file install would have to be made aware of the > > properties defined in custom.properties somehow. I have no idea where > those > > are evaluated though. > > > > /Bengt > > > > 2012/4/25 Guillaume Nodet <[email protected]> > > > > > Yes, it should be possible to do that, for to be consistent, it would > > have > > > to be done by ConfigAdmin too, else it could lead to inconsistencies > > > between what FileInstall thinks the property value is and what the > bundle > > > actually receive. So I'd be fine with any change if those are done by > > > ConfigAdmin, but if they are done by iPojo or blueprint (for example), > > i'm > > > not so sure. > > > > > > On Wed, Apr 25, 2012 at 13:36, Bengt Rodehav <[email protected]> > wrote: > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > ------------------------ > > > 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 >
