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 "Joerg Hoh (Jira)" <ji...@apache.org> on 2022/02/15 10:38:00 UTC

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

     [ https://issues.apache.org/jira/browse/OAK-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joerg Hoh resolved OAK-9612.
----------------------------
    Resolution: Fixed

> 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
>             Fix For: 1.44.0
>
>         Attachments: OAK-9612.patch
>
>
> 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)