You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Csaba Varga (JIRA)" <ji...@apache.org> on 2016/09/18 12:49:20 UTC

[jira] [Created] (OAK-4818) Version and Version History nodes don't implement the proper interfaces when found via Node.getNodes()

Csaba Varga created OAK-4818:
--------------------------------

             Summary: 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.5.10, 1.2.19, 1.0.33, 1.6
            Reporter: Csaba Varga
            Priority: Minor


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
(v6.3.4#6332)