Description
As per SLING-6383 it looks like the Oak name mapping causes for example getItem("/libs/{sub") (with a left curly bracket in the path) to return the /libs node if that exists but the supplied path does not.
I'll attach a patch with a test that demonstrates this.
fmeschbe mentions in that Sling issue that the parsing of the CR 2 section 3.2.5.1 Expanded Form could be involved, treating the left curly bracket in a special way that's not appropriate here.
Attachments
Attachments
Issue Links
- blocks
-
SLING-6383 Unexpected behavior with left curly bracket in resource resolution
- Open
- is related to
-
OAK-5410 Backport OAK-5260 (Incorrect handling of subpaths with leading left curly bracket)
- Closed
-
OAK-5367 Strange path parsing
- Open
- relates to
-
OAK-10596 Improve the test coverage of o.a.j.o.namepath.JcrPathParser
- Closed