[jira] Created: (CONFIGURATION-323) DefaultConfigurationBuilder, property-value misinterpreted as list, escaped notation of list-delimiter lost during internal processing

DefaultConfigurationBuilder, property-value misinterpreted as list, escaped notation of list-delimiter lost during internal processing
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: CONFIGURATION-323
                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-323
             Project: Commons Configuration
          Issue Type: Bug
    Affects Versions: 1.4
         Environment: WinXP
            Reporter: juergen schad


Shortly we switched from ConfigurationFactory to DefaultConfigurationBuilder for parsing out configuration-files. Unfortunately the resulting Configuration-Objects show different behaviour. The following example illustrates the problem.


{noformat}
public class CommonsConfigTest extends TestCase
{
    public void testCommonsConfig()
    {
        try
        {
            URL oConfigURL = new File("c:\\config.xml").toURL();
                       
            //========= ConfigurationFactory ===========
            final ConfigurationFactory oConfigurationFactory = new ConfigurationFactory();
            oConfigurationFactory.setConfigurationURL( oConfigURL );
            printPropertyValue( oConfigurationFactory.getConfiguration() );

            //========= DefaultConfigurationBuilder 1st attempt ===========
            final DefaultConfigurationBuilder oBuilder = new DefaultConfigurationBuilder();
            oBuilder.setURL( oConfigURL );
            printPropertyValue( oBuilder.getConfiguration() );

            //========= DefaultConfigurationBuilder 2nd attempt ===========
            final DefaultConfigurationBuilder oDelimiterBuilder = new DefaultConfigurationBuilder();
            oDelimiterBuilder.setListDelimiter( ';' );
            oDelimiterBuilder.setDelimiterParsingDisabled( true );
            oDelimiterBuilder.setURL( oConfigURL );
            printPropertyValue( oDelimiterBuilder.getConfiguration() );
        }
        catch ( Exception configEx )
        {
            configEx.printStackTrace();
        }
    }
    void printPropertyValue(final Configuration a_oConfig) {
        System.out.println( a_oConfig.getString( "demo.prop" ) );
    }
}
{noformat}

contents of config.xml
{noformat}
<?xml version="1.0" encoding="ISO-8859-1" ?>
<configuration>
    <properties optional="true" fileName="/config.properties"/>
</configuration>
{noformat}

contents of config.properties
{noformat}
demo.prop=test\, text using \,\, escaped list delimiters
{noformat}

the output looks like this
{noformat}
test, text using ,, escaped list delimiters
test
test
{noformat}

The value of demo.prop depends on the mechanism which was used to create the Configuration-objects.
Using ConfigurationFactory gives the expected result: the list delimiters are ignored as they are escaped by backslashes.
Both attempts using a DefaultConfigurationBuilder fail; even changing the List-delimiter and disabling delimiter-processing doesn't give the expected result.

One reason for the problem is the invocation of ConfigurationUtils.copy() during internel processing. The method copies the value of the property from one configuration into another. During insertion of the property, the value of the property is split (StringUtils.split) a second time. Unfortunately the escape-backslashes have already been removed, as a result of the first invocation of StringUtils.split(), which happended during the initial parsing of the file.  That's why the second split-invocation treats the value as list.

I see two problems

* the information about escape-characters is lost, copying a property from one configuration into another gives different results
* setListDelimiter() and setDelimiterParsingDisabled() don't work as expected



--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/CONFIGURATION-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595024#action_12595024 ]

Oliver Heger commented on CONFIGURATION-323:
--------------------------------------------

Thank you for this detailed bug report.

Did you check this with version 1.5 of Commons Configuration? The 1.5 release addresses some problems with list delimiter handling. Especially CONFIGURATION-283 seems to be of interest for you.

Please let us know whether this solves your problem.

> DefaultConfigurationBuilder, property-value misinterpreted as list, escaped notation of list-delimiter lost during internal processing
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CONFIGURATION-323
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-323
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: WinXP
>            Reporter: juergen schad
>
> Shortly we switched from ConfigurationFactory to DefaultConfigurationBuilder for parsing out configuration-files. Unfortunately the resulting Configuration-Objects show different behaviour. The following example illustrates the problem.
> {noformat}
> public class CommonsConfigTest extends TestCase
> {
>     public void testCommonsConfig()
>     {
>         try
>         {
>             URL oConfigURL = new File("c:\\config.xml").toURL();
>
>             //========= ConfigurationFactory ===========
>             final ConfigurationFactory oConfigurationFactory = new ConfigurationFactory();
>             oConfigurationFactory.setConfigurationURL( oConfigURL );
>             printPropertyValue( oConfigurationFactory.getConfiguration() );
>             //========= DefaultConfigurationBuilder 1st attempt ===========
>             final DefaultConfigurationBuilder oBuilder = new DefaultConfigurationBuilder();
>             oBuilder.setURL( oConfigURL );
>             printPropertyValue( oBuilder.getConfiguration() );
>             //========= DefaultConfigurationBuilder 2nd attempt ===========
>             final DefaultConfigurationBuilder oDelimiterBuilder = new DefaultConfigurationBuilder();
>             oDelimiterBuilder.setListDelimiter( ';' );
>             oDelimiterBuilder.setDelimiterParsingDisabled( true );
>             oDelimiterBuilder.setURL( oConfigURL );
>             printPropertyValue( oDelimiterBuilder.getConfiguration() );
>         }
>         catch ( Exception configEx )
>         {
>             configEx.printStackTrace();
>         }
>     }
>     void printPropertyValue(final Configuration a_oConfig) {
>         System.out.println( a_oConfig.getString( "demo.prop" ) );
>     }
> }
> {noformat}
> contents of config.xml
> {noformat}
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <configuration>
>     <properties optional="true" fileName="/config.properties"/>
> </configuration>
> {noformat}
> contents of config.properties
> {noformat}
> demo.prop=test\, text using \,\, escaped list delimiters
> {noformat}
> the output looks like this
> {noformat}
> test, text using ,, escaped list delimiters
> test
> test
> {noformat}
> The value of demo.prop depends on the mechanism which was used to create the Configuration-objects.
> Using ConfigurationFactory gives the expected result: the list delimiters are ignored as they are escaped by backslashes.
> Both attempts using a DefaultConfigurationBuilder fail; even changing the List-delimiter and disabling delimiter-processing doesn't give the expected result.
> One reason for the problem is the invocation of ConfigurationUtils.copy() during internel processing. The method copies the value of the property from one configuration into another. During insertion of the property, the value of the property is split (StringUtils.split) a second time. Unfortunately the escape-backslashes have already been removed, as a result of the first invocation of StringUtils.split(), which happended during the initial parsing of the file.  That's why the second split-invocation treats the value as list.
> I see two problems
> * the information about escape-characters is lost, copying a property from one configuration into another gives different results
> * setListDelimiter() and setDelimiterParsingDisabled() don't work as expected

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

    [ https://issues.apache.org/jira/browse/CONFIGURATION-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601409#action_12601409 ]

Oliver Heger commented on CONFIGURATION-323:
--------------------------------------------

Any news on this issue? I tend to close it as duplicate.

> DefaultConfigurationBuilder, property-value misinterpreted as list, escaped notation of list-delimiter lost during internal processing
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CONFIGURATION-323
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-323
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: WinXP
>            Reporter: juergen schad
>
> Shortly we switched from ConfigurationFactory to DefaultConfigurationBuilder for parsing out configuration-files. Unfortunately the resulting Configuration-Objects show different behaviour. The following example illustrates the problem.
> {noformat}
> public class CommonsConfigTest extends TestCase
> {
>     public void testCommonsConfig()
>     {
>         try
>         {
>             URL oConfigURL = new File("c:\\config.xml").toURL();
>
>             //========= ConfigurationFactory ===========
>             final ConfigurationFactory oConfigurationFactory = new ConfigurationFactory();
>             oConfigurationFactory.setConfigurationURL( oConfigURL );
>             printPropertyValue( oConfigurationFactory.getConfiguration() );
>             //========= DefaultConfigurationBuilder 1st attempt ===========
>             final DefaultConfigurationBuilder oBuilder = new DefaultConfigurationBuilder();
>             oBuilder.setURL( oConfigURL );
>             printPropertyValue( oBuilder.getConfiguration() );
>             //========= DefaultConfigurationBuilder 2nd attempt ===========
>             final DefaultConfigurationBuilder oDelimiterBuilder = new DefaultConfigurationBuilder();
>             oDelimiterBuilder.setListDelimiter( ';' );
>             oDelimiterBuilder.setDelimiterParsingDisabled( true );
>             oDelimiterBuilder.setURL( oConfigURL );
>             printPropertyValue( oDelimiterBuilder.getConfiguration() );
>         }
>         catch ( Exception configEx )
>         {
>             configEx.printStackTrace();
>         }
>     }
>     void printPropertyValue(final Configuration a_oConfig) {
>         System.out.println( a_oConfig.getString( "demo.prop" ) );
>     }
> }
> {noformat}
> contents of config.xml
> {noformat}
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <configuration>
>     <properties optional="true" fileName="/config.properties"/>
> </configuration>
> {noformat}
> contents of config.properties
> {noformat}
> demo.prop=test\, text using \,\, escaped list delimiters
> {noformat}
> the output looks like this
> {noformat}
> test, text using ,, escaped list delimiters
> test
> test
> {noformat}
> The value of demo.prop depends on the mechanism which was used to create the Configuration-objects.
> Using ConfigurationFactory gives the expected result: the list delimiters are ignored as they are escaped by backslashes.
> Both attempts using a DefaultConfigurationBuilder fail; even changing the List-delimiter and disabling delimiter-processing doesn't give the expected result.
> One reason for the problem is the invocation of ConfigurationUtils.copy() during internel processing. The method copies the value of the property from one configuration into another. During insertion of the property, the value of the property is split (StringUtils.split) a second time. Unfortunately the escape-backslashes have already been removed, as a result of the first invocation of StringUtils.split(), which happended during the initial parsing of the file.  That's why the second split-invocation treats the value as list.
> I see two problems
> * the information about escape-characters is lost, copying a property from one configuration into another gives different results
> * setListDelimiter() and setDelimiterParsingDisabled() don't work as expected

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/CONFIGURATION-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oliver Heger resolved CONFIGURATION-323.
----------------------------------------

       Resolution: Duplicate
    Fix Version/s: 1.5

Got no more feedback, so closing this one.

> DefaultConfigurationBuilder, property-value misinterpreted as list, escaped notation of list-delimiter lost during internal processing
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CONFIGURATION-323
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-323
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: WinXP
>            Reporter: juergen schad
>             Fix For: 1.5
>
>
> Shortly we switched from ConfigurationFactory to DefaultConfigurationBuilder for parsing out configuration-files. Unfortunately the resulting Configuration-Objects show different behaviour. The following example illustrates the problem.
> {noformat}
> public class CommonsConfigTest extends TestCase
> {
>     public void testCommonsConfig()
>     {
>         try
>         {
>             URL oConfigURL = new File("c:\\config.xml").toURL();
>
>             //========= ConfigurationFactory ===========
>             final ConfigurationFactory oConfigurationFactory = new ConfigurationFactory();
>             oConfigurationFactory.setConfigurationURL( oConfigURL );
>             printPropertyValue( oConfigurationFactory.getConfiguration() );
>             //========= DefaultConfigurationBuilder 1st attempt ===========
>             final DefaultConfigurationBuilder oBuilder = new DefaultConfigurationBuilder();
>             oBuilder.setURL( oConfigURL );
>             printPropertyValue( oBuilder.getConfiguration() );
>             //========= DefaultConfigurationBuilder 2nd attempt ===========
>             final DefaultConfigurationBuilder oDelimiterBuilder = new DefaultConfigurationBuilder();
>             oDelimiterBuilder.setListDelimiter( ';' );
>             oDelimiterBuilder.setDelimiterParsingDisabled( true );
>             oDelimiterBuilder.setURL( oConfigURL );
>             printPropertyValue( oDelimiterBuilder.getConfiguration() );
>         }
>         catch ( Exception configEx )
>         {
>             configEx.printStackTrace();
>         }
>     }
>     void printPropertyValue(final Configuration a_oConfig) {
>         System.out.println( a_oConfig.getString( "demo.prop" ) );
>     }
> }
> {noformat}
> contents of config.xml
> {noformat}
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <configuration>
>     <properties optional="true" fileName="/config.properties"/>
> </configuration>
> {noformat}
> contents of config.properties
> {noformat}
> demo.prop=test\, text using \,\, escaped list delimiters
> {noformat}
> the output looks like this
> {noformat}
> test, text using ,, escaped list delimiters
> test
> test
> {noformat}
> The value of demo.prop depends on the mechanism which was used to create the Configuration-objects.
> Using ConfigurationFactory gives the expected result: the list delimiters are ignored as they are escaped by backslashes.
> Both attempts using a DefaultConfigurationBuilder fail; even changing the List-delimiter and disabling delimiter-processing doesn't give the expected result.
> One reason for the problem is the invocation of ConfigurationUtils.copy() during internel processing. The method copies the value of the property from one configuration into another. During insertion of the property, the value of the property is split (StringUtils.split) a second time. Unfortunately the escape-backslashes have already been removed, as a result of the first invocation of StringUtils.split(), which happended during the initial parsing of the file.  That's why the second split-invocation treats the value as list.
> I see two problems
> * the information about escape-characters is lost, copying a property from one configuration into another gives different results
> * setListDelimiter() and setDelimiterParsingDisabled() don't work as expected

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.