[OAK-9612] write to a readonly builder throws a java.lang.UnsupportedOperationException

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.40.0
• Fix Version/s: 1.44.0
• Component/s: composite, core
• Assignee: Joerg Hoh
• Reporter: Joerg Hoh
• Created: 03/Nov/21 13:52
• Updated: 15/Jul/22 14:53
• Resolved: 15/Feb/22 10:37

Description

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:

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)

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).

Issue Links

• links to: GitHub Pull Request #485