You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ricky Martin (JIRA)" <ji...@apache.org> on 2010/05/31 16:50:37 UTC
[jira] Created: (CONFIGURATION-418) incorrect backslash parsing
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
Priority: Minor
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.
[jira] Updated: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ricky Martin updated CONFIGURATION-418:
---------------------------------------
Attachment: Main.java
I forgot the Main
> 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
> 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876392#action_12876392 ]
Sebb commented on CONFIGURATION-418:
------------------------------------
The escaping should not depend on whether a list delimiter is present.
Therefore the parsing needs to be done in a single pass, otherwise there will always be an ambiguity.
If parsing is done in a single pass, the code knows if the comma has been escaped or not.
The following are the possibilities - should be easy enough to parse:
{noformat}
\\ => \
\, => , but not a list delimiter
\\, => \ followed by list delimiter
\\\, => \, (not a list delimiter)
{noformat}
It's then trivial to encode property definitions:
* escape any backslashes
* escape any list delimiters that are not supposed to be list delimiters.
> 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876634#action_12876634 ]
Sebb commented on CONFIGURATION-418:
------------------------------------
@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.
[jira] Updated: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Heger updated CONFIGURATION-418:
---------------------------------------
Assignee: (was: Oliver Heger)
Fix Version/s: 2.0
Setting fix version to 2.0. I see no way to fix this problem with a reasonable effort in a compatible way.
> 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
> Priority: Minor
> Fix For: 2.0
>
> 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874181#action_12874181 ]
Ricky Martin commented on CONFIGURATION-418:
--------------------------------------------
Hi Oliver,
I checkout the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which list the keys and values.
* The PropertyConverter.diff which show how I corrected the problem (maybe too much straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
> 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
> Priority: Minor
>
> 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.
[jira] Updated: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ricky Martin updated CONFIGURATION-418:
---------------------------------------
Attachment: (was: sample.properties)
> 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
> 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876568#action_12876568 ]
Ricky Martin commented on CONFIGURATION-418:
--------------------------------------------
Yes! I just tried to say exactly what Sebb said:
{noformat}Share=\\\\share => share="\\share"
=> two backslash escaped (1 value)
test.dirs=C:\\Temp\\,D: => test.dirs=["C:\Temp\", "D:"]
=> two backslash escaped and two values (2 values)
lala=C:\\Temp\,D: => lala="C:\Temp,D:"
=> backslash escaped and comma escaped (1 value)
lala2=C:\\Temp\\\,D => lala2=["C:\Temp\D:"]
=> two backslashes escaped and comma escaped (1 value){noformat}
The problem is there is a first phase when escapes are treated and one value is returned, and a second phase when comma separated values are splitted from the String returned by previous phase, here escapes are treated again... That is the reason weird things happen.
> 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.
[jira] Issue Comment Edited: (CONFIGURATION-418) incorrect
backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874181#action_12874181 ]
Ricky Martin edited comment on CONFIGURATION-418 at 6/1/10 3:34 PM:
--------------------------------------------------------------------
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which list the keys and values.
* The PropertyConverter.diff which show how I corrected the problem (maybe too much straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
was (Author: rickyepoderi):
Hi Oliver,
I checkout the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which list the keys and values.
* The PropertyConverter.diff which show how I corrected the problem (maybe too much straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
> 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
> Priority: Minor
> Attachments: PropertyConverter.diff, sample.properties, 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.
[jira] Issue Comment Edited: (CONFIGURATION-418) incorrect
backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874181#action_12874181 ]
Ricky Martin edited comment on CONFIGURATION-418 at 6/1/10 3:38 PM:
--------------------------------------------------------------------
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
And the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which lists the keys and values.
* The PropertyConverter.diff which shows how I corrected the problem (maybe a bit straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
was (Author: rickyepoderi):
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which lists the keys and values.
* The PropertyConverter.diff which shows how I corrected the problem (maybe a bit straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
> 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
> 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.
[jira] Issue Comment Edited: (CONFIGURATION-418) incorrect
backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874181#action_12874181 ]
Ricky Martin edited comment on CONFIGURATION-418 at 6/1/10 3:35 PM:
--------------------------------------------------------------------
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which lists the keys and values.
* The PropertyConverter.diff which shows how I corrected the problem (maybe a bit straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
was (Author: rickyepoderi):
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which lists the keys and values.
* The PropertyConverter.diff which shows how I corrected the problem (maybe too much straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
> 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
> Priority: Minor
> Attachments: PropertyConverter.diff, sample.properties, 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.
[jira] Updated: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ricky Martin updated CONFIGURATION-418:
---------------------------------------
Attachment: sample.properties
sample.properties
PropertyConverter.diff
The three files commented to test the issue.
> 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
> Priority: Minor
> Attachments: PropertyConverter.diff, sample.properties, 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876769#action_12876769 ]
Oliver Heger commented on CONFIGURATION-418:
--------------------------------------------
PropertiesConfiguration allows setting an IOFactory which is responsible for creating the readers and writers for reading and writing properties files. So we could provide alternative implementations which handle backslash escaping correctly. I have difficulties to find a meaningful name for these alternative implementations. Maybe _StringentPropertiesReader_?
> 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.
[jira] Issue Comment Edited: (CONFIGURATION-418) incorrect
backslash parsing
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874155#action_12874155 ]
Oliver Heger commented on CONFIGURATION-418:
--------------------------------------------
It may be that the current version in subversion contains some changes related to the handling of backslahses and escaping, but I am not sure. So would it be possible for you to checkout the most recent version and test with it? Otherwise I will have a look in some days. Thanks.
> 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
> Priority: Minor
>
> 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (CONFIGURATION-418) incorrect
backslash parsing
Posted by "Ricky Martin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874181#action_12874181 ]
Ricky Martin edited comment on CONFIGURATION-418 at 6/1/10 3:35 PM:
--------------------------------------------------------------------
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which lists the keys and values.
* The PropertyConverter.diff which shows how I corrected the problem (maybe too much straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
was (Author: rickyepoderi):
Hi Oliver,
I checked out the trunk:
$ svn checkout http://svn.apache.org/repos/asf/commons/proper/configuration/trunk
An the error is still the same. I send you the files and my straight forward diff:
* Little sample.properties which shows the problem.
* A direct Main.java which list the keys and values.
* The PropertyConverter.diff which show how I corrected the problem (maybe too much straight forward).
The result of the Main.java using sample.properties is the following:
share1=[\share1, \share1]
share2=[\\share2, \\share2]
Which clearly shows the different behavior if comma separated is used or not.
Thanks!
> 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
> Priority: Minor
> Attachments: PropertyConverter.diff, sample.properties, 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876049#action_12876049 ]
Oliver Heger commented on CONFIGURATION-418:
--------------------------------------------
Thanks for the proposed patch. It solves the problem described by this issue, but unfortunately causes another unit test to fail.
Our rules for escaping list delimiters and other escaping characters have become so complex that it is easy to lose overview. Per default, a comma is interpreted as list delimiter character. This can be escaped by a backslash as in
{{options = 1\, 2 or 3}}.
Now there is often the requirement to store path names in configuration files. In Windows environments this can cause problems with the escaping of the list delimiter, e.g.:
{{test.dirs = C:\\Temp\\,D:\\data}}
Here the trailing backslash of the first list element would be interpreted as escape character for the list delimiter. Therefore it is also possible to escape the escape character for the list delimiter:
{{test.dirs = C:\\Temp\\\\,D:\\data}}
This is the reason for the condition {{&& c != LIST_ESC_CHAR}} which your patch removed.
In your case you use names of network shares starting with a double backslash. If multiple of these shares are declared in a single line using a list delimiter, these duplicated backslashes are interpreted as escaped backslashes and so one of them is removed. This escaping is only evaluated if a list delimiter is involved, so the properties actually have to look different if they are defined in a single line or in multiple lines. I think, the user guide has to be updated to reflect this.
To avoid escaping you have to duplicate the backslahes again. Your example then becomes:
{{test.share1 = \\\\\\\\share1a, \\\\\\\\share1b}}
However, when testing I found that there is still a bug in the escaping logic which does not handle such constellations correctly. I am working on a fix.
> 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.
[jira] Commented: (CONFIGURATION-418) incorrect backslash parsing
Posted by "Oliver Heger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CONFIGURATION-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876386#action_12876386 ]
Oliver Heger commented on CONFIGURATION-418:
--------------------------------------------
Well, to be honest, I am not happy with the current state either. It is pretty complex and hard to understand. However, given the requirements, I do not know how we can make it simpler:
* If a property value can contain a list delimiter, there must be a possibility to escape it.
* Then there must be a way to escape the sequence of an escaped list delimiter.
I am open for suggestions. I am currently updating the user guide, and I hope this helps a bit to grasp the concept.
> 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.