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 Tue, 08 Jun 2010 05:49:14 GMT

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

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

Just to make sure I understand you correctly: With parsing in two passes you mean that the
presence of a list delimiter influences the escaping algorithm, so that list elements may
have to be defined in a different way when they are put on a single line or on multiple lines,
right?

Yes, I agree, this should be made consistent. I don't know why it is currently implemented
this way, but the code is there probably for a long time now. So I wonder whether we should
change the parsing in a minor release because this impacts the way certain properties have
to be defined and might break existing applications. Therefore I tend to close this ticket
(a bug actually has been fixed) and open a new one, targeted to a 2.0 release, with the goal
to rework the parsing algorithm. WDYT?

> 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