jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Csaba Varga (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-4818) Version and Version History nodes don't implement the proper interfaces when found via Node.getNodes()
Date Mon, 07 May 2018 19:13:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466337#comment-16466337
] 

Csaba Varga commented on OAK-4818:
----------------------------------

I've created a pull request to help with the progress on this ticket: [https://github.com/apache/jackrabbit-oak/pull/87]

The only difference compared to the patch attached here is that the code is throwing an IllegalStateException
when an error occurs instead of falling back to the old behavior. Throwing an error when unexpected
things happen is a lot cleaner than trying to continue with an incorrect solution.

Please let me know if I should provide backport PRs for the 1.8 and 1.6 branches as well.

> Version and Version History nodes don't implement the proper interfaces when found via
Node.getNodes()
> ------------------------------------------------------------------------------------------------------
>
>                 Key: OAK-4818
>                 URL: https://issues.apache.org/jira/browse/OAK-4818
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: jcr
>    Affects Versions: 1.0.33, 1.2.19, 1.5.10, 1.6.0
>            Reporter: Csaba Varga
>            Priority: Minor
>         Attachments: version-traversal-issue.patch
>
>
> The JCR spec says in section 15.6:
> When an nt:versionHistory or nt:version node is acquired through a query or directly
through a getNode, the actual Java type of the returned object must be VersionHistory (in
the case nt:versionHistory nodes) or Version (in the case of nt:version nodes).
> While this doesn't explicitly mention the getNodes() method, I believe it's a reasonable
expectation that this method should work the same way, i.e. make the actual Java type of the
returned child object Version or VersionHistory where applicable. Oak currently doesn't work
this way; the iterator returned by either getNodes() overload will always yield NodeImpl instances.
> I will attach a suggested patch to fix this, including addition to the unit tests to
catch any regressions in the future. The patch is against the latest trunk, but the same behavior
seems to be present in all past versions as well, so if it's not a big problem, could you
also backport this to older stable versions as well? (My employer is using AEM 6.1 currently,
so we would be interested in getting this backported to 1.2 at least.)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message