You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Matt Juntunen (Jira)" <ji...@apache.org> on 2022/05/11 12:14:00 UTC

[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent

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

Matt Juntunen commented on CONFIGURATION-753:
---------------------------------------------

Coming in late to this discussion...

The main cause of the inconsistency here seems to be the interaction between {{DefaultConversionHandler}} and {{ConfigurationInterpolator}}. In the case where the property value consists of only a variable reference, the {{ConfigurationInterpolator}} returns the actual collection object instead of a string. {{DefaultConversionHandler}} then attempts to convert the "complex" object to a string and chooses the first entry from the collection. However, if the property value contains more than just the variable reference, then {{ConfigurationInterpolator}} uses {{StringSubstitutor}} to construct the final string. {{StringSubstitutor}} does not contain the complex string conversion logic that {{DefaultConversionHandler}} has and simply uses {{Objects.toString()}}, producing the inconsistency noted in this ticket.

Here are my thoughts on how to address this:
1. Rework the API so that {{ConfigurationInterpolator}} can call back into a {{ConversionHandler}} to convert values to strings. This would produce the most consistent results overall and would prevent us from having similar conversion logic in both classes. 
2. Do nothing. We can document the fact that single variable interpolation can return different values than interpolation with variables and non-variables. I believe this is internally consistent behavior even though it may not be the expected behavior at times.

I plan on looking into the first option more. Thoughts?

> Handling of interpolation is inconsistent
> -----------------------------------------
>
>                 Key: CONFIGURATION-753
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
>             Project: Commons Configuration
>          Issue Type: Bug
>          Components: Interpolation
>    Affects Versions: 2.5
>         Environment: Java 8, Configurations2 2.5
>            Reporter: Peter
>            Priority: Major
>         Attachments: test.properties
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation elsewhere, the behaviour is inconsistent. There are other tickets/discussions about whether it should just pick the first value or not, but I don't think it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder<FileBasedConfiguration> builder = new FileBasedConfigurationBuilder<FileBasedConfiguration>(PropertiesConfiguration.class)
>     .configure(params.fileBased()
>         .setFileName("/tmp/test.properties")
>       );
> try {
>     FileBasedConfiguration config = builder.getConfiguration();
>     System.out.println(config.getString("foo.one"));
>     System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
>     // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello 
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more intuitive if both cases were handled the same.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)