On 21.5.12 17:10, Julian Reschke wrote:
On 2012-05-16 14:40, Julian Reschke wrote:
On 2012-05-15 23:26, Julian Reschke wrote:
...
Summarizing from a chat I just did with Jukka:
1) one goal for the path mapping (JCR->OAK) is to have as many cases as
possible where we don't have to map:
a) if a path does not contain one of "{}:[]", we don't need to map
b) if the current session has no active namespace remappings and the
path does not contain one of "{}[]", we don't need to map. (Note that
this mean that we can leave /parent/child/jcr:content alone if no
namespaces have been remapped)
2) Have the path mapper (JCR->OAK) deal just with prefix rewriting and
expanded name resolution, and return either the original String (taking
the potential shortcuts into account) or the mapped String
3) For JCR methods that create new nodes (addNode, destination path in
copy / move), have a method that splits into parent path and child name.
The latter can be checked for the presence of [] then (in which case the
method can throw)
4) In general, do not normalize paths, just walk the internal node tree.
4a) Note that this assumes that we "walk" the tree (for some value of
"walk") without being stopped by access control.
Feedback appreciated, Julian
I just had a look at the current code, and it seems the right way to
proceed is to remove the following parts from JcrPathParser:
- identifier paths (we already do this elsewhere)
- index handling (maybe except for syntax checks)
- . and .. handling
So this was leave us with:
- syntax checks
- expanded name resolution
- prefix rewriting
I just tried this and it breaks only the NamePathParserImplTests (that
assume this code is there), and a few TCK cases that make assuptions of
index handling (which we'll do somewhere else as well).
I'm fine with such a change. However we will need to take that relative
path segments (. and ..) are never passed to the Oak API. That is,
node.getNode("foo/../../bar")
should not pass this path verbatim to the Oak API.
Michael
