[
https://issues.apache.org/jira/browse/JCRVLT-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781424#comment-17781424
]
Julian Reschke commented on JCRVLT-724:
---------------------------------------
We can still do that in the future, although I'd prefer if Oak implemented the
JCR API properly.
The current fix for JCRVLT-724 will help in any case - so far OAK-10523 is just
a theory what lead us here - let's confirm that first before adding workarounds
to Oak.
> DocViewSaxFormatter: improve diagnostics when generating DocViewNode2 from
> JCR node
> -----------------------------------------------------------------------------------
>
> Key: JCRVLT-724
> URL: https://issues.apache.org/jira/browse/JCRVLT-724
> Project: Jackrabbit FileVault
> Issue Type: Task
> Components: vlt
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
> Fix For: 3.7.2
>
> Attachments: SameNameSiblingIT.java
>
>
> See
> <[https://github.com/apache/jackrabbit-filevault/blob/c0480b9f83ede8969d8bcaf03428a35f81d146c2/vault-core/src/main/java/org/apache/jackrabbit/vault/util/DocViewNode2.java#L91-L110]>
> We have the unfortunate condition that an existing repository apparently
> contains invalid node names. The code above gets an IllegalNameException from
> {{nameresolver.getQName()}}, but that code doesn't have the full path to the
> node (well, it shouldn't exist in the first place...).
> It might be good to catch that exception and add information about the node's
> path and rethrow it, either where or in the calling code
> ({{AggregateImpl.walk()}}?).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
