[jira] [Commented] (OAK-9612) write to a readonly builder throws a java.lang.UnsupportedOperationException

["Joerg Hoh (Jira)" <ji...@apache.org>]

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

Joerg Hoh commented on OAK-9612:
--------------------------------

[~angela] My idea is to define a new {{ModificationOnReadOnlyBuilderException extends RuntimeException}} type, which is thrown instead of the RuntimeException at this place, and catch this exception at a location in above's stacktrace, where the signature allows to throw a {{ConstraintViolationException}}; then instead of rethrowing the {{ModificationOnReadOnlyBuilderException}} we throw a {{ConstraintViolationException}}, which any consumer of the JCR API is forced to deal with.

> write to a readonly builder throws a java.lang.UnsupportedOperationException
> ----------------------------------------------------------------------------
>
>                 Key: OAK-9612
>                 URL: https://issues.apache.org/jira/browse/OAK-9612
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: composite, core
>    Affects Versions: 1.40.0
>            Reporter: Joerg Hoh
>            Priority: Major
>
> I have a setup with a composite nodestore, where a write operation is attempted on the read-only part of it. It throws an UnsupportedOperationException and the stacktrace is like this:
> {noformat}
> java.lang.UnsupportedOperationException: This builder is read-only.
>         at org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.unsupported(ReadOnlyBuilder.java:44)
>         at org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder.setChildNode(ReadOnlyBuilder.java:200)
>         at org.apache.jackrabbit.oak.core.SecureNodeBuilder.setChildNode(SecureNodeBuilder.java:314)
>         at org.apache.jackrabbit.oak.plugins.tree.impl.AbstractMutableTree.addChild(AbstractMutableTree.java:75)
>         at org.apache.jackrabbit.oak.core.MutableTree.addChild(MutableTree.java:199)
>         at org.apache.jackrabbit.oak.plugins.tree.TreeUtil.addChild(TreeUtil.java:247)
>         at org.apache.jackrabbit.oak.jcr.delegate.NodeDelegate.addChild(NodeDelegate.java:690)
>         at org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:314)
>         at org.apache.jackrabbit.oak.jcr.session.NodeImpl$5.perform(NodeImpl.java:280)
>         at org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:209)
>         at org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>         at org.apache.jackrabbit.oak.jcr.session.NodeImpl.addNode(NodeImpl.java:280)
>         at org.apache.jackrabbit.oak.jcr.session.NodeImpl.addNode(NodeImpl.java:265)
>         at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.create(JcrResourceProvider.java:448)
> {noformat}
> Right now this exception is not handled at any layer in Oak, Sling and our code, but it rather bubbles up to the request which has initiated it. Any exception handling which is present to handle failed writes (for whatever reason) is not triggered, because it just catches the exceptions which are thrown according to the API spec of addNode().
> In this scenario this exception is expected (from the setup point of view, not necessarily from the code itself), and I would appreciate if this UnsupportedOperationException could be converted by Oak into a ConstraintViolationException, which we handle already (including the message that this operation is not supported on a ReadOnlyBuilder). 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)