commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CONFIGURATION-418) incorrect backslash parsing
Date Tue, 08 Jun 2010 11:26:14 GMT

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

Sebb edited comment on CONFIGURATION-418 at 6/8/10 7:24 AM:
------------------------------------------------------------

@Oliver: yes, two-pass parsing means that the escaping requirements depend on whether list
delimiters are present or not.

I'm not sure how one can properly handle the behaviour change. It's a bit different from an
API change, as it is the data that would need to be fixed, rather than code. This makes it
much harder for users to deal with, as the data may even not be theirs. So breaking compatibility
would mean that some users cannot upgrade.

So I think the only way forward now would be to add the new behaviour as an option. Perhaps
as a ctor argument. Or maybe a new class.

Not sure a new JIRA is needed; but if so, it should be linked to this one.

      was (Author: sebb@apache.org):
    @Oliver: yes, two-pass parsing means that the escaping requirements depend on the presence
of list delimiters.

I'm not sure how one can properly handle the behaviour change. It's a bit different from an
API change, as it is the data that would need to be fixed, rather than code. This makes it
much harder for users to deal with, as the data may even not be theirs. So breaking compatibility
would mean that some users cannot upgrade.

So I think the only way forward now would be to add the new behaviour as an option. Perhaps
as a ctor argument. Or maybe a new class.

Not sure a new JIRA is needed; but if so, it should be linked to this one.
  
> 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