[
https://issues.apache.org/jira/browse/OAK-9612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated OAK-9612:
---------------------------
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:
{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 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).
was:
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).
> 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 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)
