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>) 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

Reply via email to