[jira] [Issue Comment Edited] (SLING-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap

["Alexander Klimetschek (Issue Comment Edited) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229309#comment-13229309 ] 

Alexander Klimetschek edited comment on SLING-2425 at 3/14/12 4:32 PM:
-----------------------------------------------------------------------

Sorry if my original description was unclear. The issue I have is that I can't read certain properties via the ValueMap, that can be created using the JCR API and the Sling POST servlet:

1. create properties:

curl -u admin:admin -F "-prop=value" -F "1prop=value" http://localhost:8080/tmp

2. try to read them:

ValueMap map = resolver.getResource("/tmp").adaptTo(ValueMap.class);
map.get("-prop", String.class); // fails, returns null
map.get("1prop", String.class); // fails, returns null

My current workaround (due to the fact that the encoding is not done in the cached variant):

// right after fetching the map
map.size(); // triggers readFully() internally
map.get("1prop", String.class); // returns "value"

Property names starting with "-" or numbers are affected (and more). (Agree this is a rare case, but in our use case we need to resort to a specific naming to separate these properties from others. And these are perfectly valid in JCR.)
                
      was (Author: alexander.klimetschek):
    Sorry if my original description was unclear. The issue I have is that I can't read certain properties via the ValueMap, that can be created using the JCR API and the Sling POST servlet:

1. create properties:

curl -u admin:admin -F "-prop=value" -F "1prop=value" http://localhost:8080/tmp

2. try to read them:

ValueMap map = resolver.getResource("/tmp").adaptTo(ValueMap.class);
map.get("-prop", String.class); // fails
map.get("1prop", String.class); // fails

My current workaround (due to the fact that the encoding is not done in the cached variant):

// right after fetching the map
map.size(); // triggers readFully() internally
map.get("1prop", String.class); // returns "value"

Property names starting with "-" or numbers are affected (and more). (Agree this is a rare case, but in our use case we need to resort to a specific naming to separate these properties from others. And these are perfectly valid in JCR.)
                  
> Incorrect and inconsistent escaping of property names used in JcrPropertyMap
> ----------------------------------------------------------------------------
>
>                 Key: SLING-2425
>                 URL: https://issues.apache.org/jira/browse/SLING-2425
>             Project: Sling
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: JCR Resource 2.0.10
>            Reporter: Alexander Klimetschek
>            Assignee: Carsten Ziegeler
>
> The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants.
> 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example "-" is valid, while it is not allowed in ISO9075 and becomes "_x002d_"). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0]
> 2) Inconsistency:
> a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant
> b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode()
> Hence for all valid JCR names, which are not valid under ISO9075 (like "1_prop", "-foo"), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced "arbitrary" escaping.
> I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary & undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API).
> [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira