commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Date Sun, 27 Jun 2010 19:39:51 GMT

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

Oliver Heger commented on CONFIGURATION-418:
--------------------------------------------

The problem is worse than I thought. This two-pass parsing is already (indirectly) performed
by the addProperty() method in the AbstractConfiguration base class. So all configuration
classes derived from this class (basically all) are affected in theory. Currently you have
to use different escaping for backslashes when you call addProperty() with a value containing
a list delimiter or for a value without a delimiter. Because many file-based configurations
call addProperty() in their load() method loading of configuration files is also affected
in many cases - but not in all: XMLConfiguration for instance is using a different strategy
for splitting property values.

One approach to solve this problem and make handling of list delimiters and escape characters
more consistent would be to introduce a new interface - maybe {{ListDelimiterHandler}} - and
delegate parsing of property values to a concrete implementation. It has to be ensured then
that all split operations for property values are done through this interface. Probably this
interface also has to be used when writing configuration files because the escaping performed
by write has to be compatible with the parsing done when adding properties.

However, I doubt whether this is worth the effort. Would really anybody provide a custom implementation
of such an interface or is it easier to work around the current inconsistencies (provided
they are well documented)? Also, there is still the issue with backwards compatibility of
existing configuration files which may be affected when we change the current behavior.

> incorrect backslash parsing
> ---------------------------
>
>                 Key: CONFIGURATION-418
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-418
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.6
>         Environment: Commons Configuration 1.6
>            Reporter: Ricky Martin
>            Assignee: Oliver Heger
>            Priority: Minor
>         Attachments: Main.java, PropertyConverter.diff, sample.properties
>
>
> I am using Commons Configuration (PropertiesConfiguration) and some of my data are windows
shares: \\share1 or \\share2. The problem is the parsing return different things depending
how the keys are defined. For example, these keys
> share=\\\\share1
> share=\\\\share2
> are different than:
> share=\\\\share1, \\\\share2
> The first one returns two backslashes ("\\share1" and "\\share2") and the second returns
just one ("\share1" and "\share2"). I think the problem is in PropertyConverter line 525,
cos the backslash is hidden twice when multivalue parsing is done:
> if (c != delimiter && c != LIST_ESC_CHAR) 
>                 {
>                     // no, also add escape character
>                     token.append(LIST_ESC_CHAR);
>                 }
> In my understanding the second condition produces this strange issue and it should be
like this:
> if (c != delimiter) 
>                 {
>                     // no, also add escape character
>                     token.append(LIST_ESC_CHAR);
>                 }
> Check that cos I can be missing something...
> TIA

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


Mime
View raw message