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

Michael Dürig commented on OAK-4818:
------------------------------------

Most of those exceptions should never actually occur on that code path. The 
others are {{IllegalItemStateException}} instances indicating the iterator is 
not valid any more. This suggest that we could as well throw an 
{{IllegaleStateException}} instead of logging and carrying on (like we already 
do e.g. in {{NodeImpl#getNodes()}}). 

But I agree, there is not silver bullet here. This is one of the places where 
the JCR API puts us into a hard place. 

> 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.6, 1.0.33, 1.2.19, 1.5.10
>            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
(v6.3.4#6332)

Reply via email to