After browsing through the code it seems like this is already implemented. The InterpolationHelper was updated to support this in
https://issues.apache.org/jira/browse/FELIX-2663 (by yourself I believe Guillaume). This should be part of version 1.1.0 of Felix utils. Fileinstall uses 1.1.0 of Felix utils. It is marked as a private package and is therefore colocated in the fileinstall bundle. Looking at fileinstall it also seems like it is updated to pass the bundle context to InterpolationHelper. All in all, it seems like this has already been resolved... Now, why doesn't it work for me then? I will do a few more tests to verify that I'm not lying about this, /Bengt 2012/4/25 Bengt Rodehav <[email protected]> > Will do... > > > 2012/4/25 Guillaume Nodet <[email protected]> > >> Sure, and if you could provide a patch, that would be awesome of course >> ;-) >> >> On Wed, Apr 25, 2012 at 14:14, Bengt Rodehav <[email protected]> wrote: >> >> > 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 >> > > >> > >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> FuseSource, Integration everywhere >> http://fusesource.com >> > >
