commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricky Martin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Date Mon, 07 Jun 2010 07:14:13 GMT

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

Ricky Martin commented on CONFIGURATION-418:
--------------------------------------------

I understand Oliver, although it is a bit weird. So when you need more than one consecutive
backslash in a comma separated key you need to escape them twice (one for the general escaping
and a second for comma separated parsing). 

What I do not know it is why comma separated parsing is performed in a second phase... That
is the final reason for this mess, but I am sure that exceeds me ;-)

Thanks a lot!

> 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