[jira] [Commented] (OAK-426) OAK-API: Deal with names and relativePaths consisting/containing . and ..
[
https://issues.apache.org/jira/browse/OAK-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529838#comment-13529838
]
Jukka Zitting commented on OAK-426:
---
bq. yes, i listed them above and marked them in code.
I found {{LocationUtil}} and {{NodeUtil.getOrAddTree()}} that are used by
{{OakAuthorizableProperties}} and {{UserProvider}}. Are there other places
where we need this? If not, what do the latter classes use/need non-normalized
paths for?
OAK-API: Deal with names and relativePaths consisting/containing . and ..
-
Key: OAK-426
URL: https://issues.apache.org/jira/browse/OAK-426
Project: Jackrabbit Oak
Issue Type: New Feature
Components: core
Reporter: angela
Fix For: 0.6
i just run into another place where i would need to work around
missing support for the current (.) and parent (..) element
in the TreeLocation.
IMO it would make sense to add this to TreeLocation#getChild... maybe
even rename it to TreeLocation#getLocation(String relativePath)?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-426) OAK-API: Deal with names and relativePaths consisting/containing . and ..
[
https://issues.apache.org/jira/browse/OAK-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529852#comment-13529852
]
Michael Dürig commented on OAK-426:
---
bq. the commit that was marked to fix that issue was vetoed as it apparently
was not complete and therefore required tests to be commented out.
I commented the test out because it failed due to it improperly passing a JCR
path directly down to the Oak API. This went unnoted before since the ad-hoc
solution with {{LocationUtil}} is more lenient wrt. to paths than my proposed
solution. So I think I had good reasons to comment that test out. I'd had
expected you to take a look and come up with a more constructive comment as
just calling it a hack.
OAK-API: Deal with names and relativePaths consisting/containing . and ..
-
Key: OAK-426
URL: https://issues.apache.org/jira/browse/OAK-426
Project: Jackrabbit Oak
Issue Type: New Feature
Components: core
Reporter: angela
Fix For: 0.6
i just run into another place where i would need to work around
missing support for the current (.) and parent (..) element
in the TreeLocation.
IMO it would make sense to add this to TreeLocation#getChild... maybe
even rename it to TreeLocation#getLocation(String relativePath)?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-426) OAK-API: Deal with names and relativePaths consisting/containing . and ..
[ https://issues.apache.org/jira/browse/OAK-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13526406#comment-13526406 ] Michael Dürig commented on OAK-426: --- In revision 1418316 I implemented a solution based on 2. in http://markmail.org/message/7hhm6m36uuxbuna7 OAK-API: Deal with names and relativePaths consisting/containing . and .. - Key: OAK-426 URL: https://issues.apache.org/jira/browse/OAK-426 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: angela i just run into another place where i would need to work around missing support for the current (.) and parent (..) element in the TreeLocation. IMO it would make sense to add this to TreeLocation#getChild... maybe even rename it to TreeLocation#getLocation(String relativePath)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-426) OAK-API: Deal with names and relativePaths consisting/containing . and ..
[ https://issues.apache.org/jira/browse/OAK-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496272#comment-13496272 ] Jukka Zitting commented on OAK-426: --- Do we have a concrete case where a piece of code needs to navigate up the tree hiearachy, and can't easily do so with the existing features? OAK-API: Deal with names and relativePaths consisting/containing . and .. - Key: OAK-426 URL: https://issues.apache.org/jira/browse/OAK-426 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: angela i just run into another place where i would need to work around missing support for the current (.) and parent (..) element in the TreeLocation. IMO it would make sense to add this to TreeLocation#getChild... maybe even rename it to TreeLocation#getLocation(String relativePath)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
