[
https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229070#comment-13229070
]
Felix Meschberger commented on SLING-2425:
------------------------------------------
I think encoding is absolutely required. The application does not have to care
about whether and how the persistence layer supports the property names. The
ValueMap implementation has to cope with this properly and transparently.
However, if the Jackrabbit suggested way of encoding is not ISO 9075 but
Jackrabbit's own encoding, then we should abide by this rule. Yet, there is
another text on encoding: Section 3.2.5.4, Exposing Non-JCR Names, of the JCR 2
spec. Extrapolating from that, yet another encoding might be stipulated using
private-use Unicode characters...
Can we not handle this in a backwards compatible manner ?
* When creating properties, the Jackrabbit encoding is used
* When updating properties: either the Jackrabbit encoding isued (removing
the property with the old encoding)
* When deleting properties, we use the encoding of the original property
* When reading with read all we check the encoding:
- if the string contains /_x[0-9a-fA-F]{4}_/ then use ISO decoding
- if the string contains /%[0-9a-fA-F]{2}/ then use Jackrabbit decoding
- else don't decode at all
* When reading an uncached value both encodings should be tried
Of course, the internal read and readall methods should behave the same -
support whatever encoding is used in the repository but internally cache
un-encoded. I do not understand where your problem really is here (you didn't
fully disclose it).
As for documentation: This behaviour should probably be documented in the
JcrPropertyMap class exposed from the JCR Resource bundle.
> 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
