[
https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257749#comment-13257749
]
Alexander Klimetschek edited comment on SLING-2425 at 4/19/12 8:14 PM:
-----------------------------------------------------------------------
Sorry, I thought all dots get escaped by Text.escapeIllegalJcrChars. But most
work, only using "node/../prop" doesn't work.
Added attachment SLING-2425-test-dots.patch which adds tests with "./prop"
"node/prop" and "node/../prop" where the last one currently fails.
was (Author: alexander.klimetschek):
Adds tests with "./prop" "node/prop" and "node/../prop" where the last one
currently fails.
> 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
> Fix For: JCR Resource 2.1.0
>
> Attachments: SLING-2425-test-dots.patch
>
>
> 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
