OK, thanks, /Bengt
2012/6/10 Jean-Baptiste Onofré <[email protected]> > Hi Bengt, > > sorry, not yet. I will tackle that in the coming week. > > > I will keep you posted. > > Regards > JB > > On 06/10/2012 11:05 AM, Bengt Rodehav wrote: > >> Hello JB, >> >> Just wanted to check if you've had any luck getting a Felix committer >> interested in this JIRA. I would really like to get this fix done since >> I'm a "heavy" user of custom.properties in Karaf. >> >> /Bengt >> >> 2012/5/16 Bengt Rodehav <[email protected] <mailto:[email protected]>> >> >> >> Thanks a lot JB, >> >> /Bengt >> >> >> 2012/5/16 Jean-Baptiste Onofré <[email protected] >> <mailto:[email protected]>> >> >> >> Hi Bengt, >> >> We have some Felix committer in the Karaf community. We can >> think about a patch (in Karaf and/or Felix FileInstall). >> >> Let me see with Felix guys, I will keep you posted. >> >> Regards >> JB >> >> >> On 05/16/2012 09:08 AM, Bengt Rodehav wrote: >> >> I use the possibility to define variables in a >> custom.properties file >> that I can later use in different config admin configuration >> files. This >> works very well and makes it a lot easier to customise a >> Karaf installation. >> >> However, to make this work I've had to disable fileinstall's >> feature of >> writing back configuration changes to the configuration >> files - a >> functionality that I, for other reasons, would really like >> to use. >> >> The problem is that the properties defined as "framework >> properties" >> (defined in config.properties and files included (like >> custom.properties)) are not resolved by file install. I have >> discussed >> this on the Felix mailing list and I've also created a JIRA >> >> (https://issues.apache.org/__**jira/browse/FELIX-3487<https://issues.apache.org/__jira/browse/FELIX-3487> >> >> <https://issues.apache.org/**jira/browse/FELIX-3487<https://issues.apache.org/jira/browse/FELIX-3487>>) >> for this >> >> (and >> attached a patch). No one seems to have picked up this yet >> and I guess >> it might not be that important for pure Felix users. >> However, as a Karaf >> user I think this is really important and I was hoping that >> perhaps some >> Karaf developer would like to get this fixed. >> >> An example of the consequence is: >> >> 1. Define a variable in custom.properties defining the >> folder where log >> files will reside, e g: >> >> logdir=C:/myinstallation/log >> >> 2. Use that property in the configuration file for logging >> (org.ops4j.pax.logging.cfg), e g: >> >> log4j.appender.debug.file=${__**logdir}/debug.log >> >> >> 3. The above works fine (the correct logdir is used). >> However, if I >> change anything in that configuration file then the >> ${logdir} variable >> will be substituted for the evaluated value. E g the >> configuration file >> will be changed to: >> >> log4j.appender.debug.file=C:/_**_myinstallation/debug.log >> >> >> This is of course highly undesirable and has caused me to >> disable file >> install's write-back functionality. >> >> The underlying reason for this (I think I explained it in >> the JIRA) is >> that normally file install does not write-back properties >> that has not >> changed. But since file install does not resolve framework >> properties, >> it falsely assumes that the property has changed and >> replaces the >> original value with the value from config admin (which is >> evaluated). >> Everything works fine with variables defined in the same >> configuration >> file and with system properties but not with framework >> properties. >> >> I would really like this fix in the next release of Karaf if >> possible. >> >> Long term I would like to explore the possiblity to preserve >> variables >> even when the configuration property using the variable has >> changed. It >> would be a great benefit I think. For now, I'll settle for not >> overwriting variables that haven't changed. >> >> /Bengt >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
