Joerg Hoh created OAK-9612:
------------------------------
Summary: write to a readonly builder throws an
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
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, and I would appreciate 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.3.4#803005)
