[
https://issues.apache.org/jira/browse/JCR-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Kaar updated JCR-1055:
-----------------------------
Description:
I have found a behavior that does not seem to be consistent with the
spec:
After replacing a node with importXML using
IMPORT_UUID_COLLISION_REPLACE_EXISTING the new node is not at the position of
the replaced node (talking about the position among the siblings).
The origininal node is removed, but the new node is created as the last child
of the parent node, and not spec-compliant at the position of the replaced node.
Here how I use it:
// assume Session s, Node n, String text (holding XML data)
s.importXML(
n.getPath(),
new ByteArrayInputStream (text.getBytes("UTF-8")),
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING
);
s.save();
And here a quote from the spec section 7.3.6
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING:
If an incoming referenceable node has the same UUID as a node already existing
in the workspace then the already existing node is replaced by the incoming
node in the same position as the existing node.
[note "same position"]
another strange effect is, that after importing the node i cannot access it. An
InvalidItemStateException is thrown, although the node with te given ID is
present ( at the wrong position)
here the stacktrace:
javax.jcr.InvalidItemStateException:
1321d317-43b4-4599-84ad-c6ac41167942: the item does not exist anymore
at org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:157)
at org.apache.jackrabbit.core.NodeImpl.getParent(NodeImpl.java:1903)
at
at.onlaw.redsys.KommentarManager.replaceText(KommentarManager.java:479)
at org.apache.jsp.editNE_jsp._jspService(editNE_jsp.java:94)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
was:
I have found a behavior that does not seem to be consistent with the
spec:
After replacing a node with importXML using
IMPORT_UUID_COLLISION_REPLACE_EXISTING the new node is not at the position of
the replaced node (talking about the position among the siblings).
The origininal node is removed, but the new node is created as the last child
of the parent node, and not spec-compliant at the position of the replaced node.
Here how I use it:
// assume Session s, Node n, String text (holding XML data)
s.importXML(
n.getPath(),
new ByteArrayInputStream (text.getBytes("UTF-8")),
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING
);
s.save();
And here a quote from the spec section 7.3.6
ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING:
If an incoming referenceable node has the same UUID as a node already existing
in the workspace then the already existing node is replaced by the incoming
node in the same position as the existing node.
[note "same position"]
> Incorrect node position after import
> ------------------------------------
>
> Key: JCR-1055
> URL: https://issues.apache.org/jira/browse/JCR-1055
> Project: Jackrabbit
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Marcus Kaar
>
> I have found a behavior that does not seem to be consistent with the
> spec:
> After replacing a node with importXML using
> IMPORT_UUID_COLLISION_REPLACE_EXISTING the new node is not at the position of
> the replaced node (talking about the position among the siblings).
> The origininal node is removed, but the new node is created as the last child
> of the parent node, and not spec-compliant at the position of the replaced
> node.
> Here how I use it:
> // assume Session s, Node n, String text (holding XML data)
> s.importXML(
> n.getPath(),
> new ByteArrayInputStream (text.getBytes("UTF-8")),
> ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING
> );
> s.save();
>
> And here a quote from the spec section 7.3.6
> ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING:
> If an incoming referenceable node has the same UUID as a node already
> existing in the workspace then the already existing node is replaced by the
> incoming node in the same position as the existing node.
> [note "same position"]
> another strange effect is, that after importing the node i cannot access it.
> An InvalidItemStateException is thrown, although the node with te given ID is
> present ( at the wrong position)
> here the stacktrace:
> javax.jcr.InvalidItemStateException:
> 1321d317-43b4-4599-84ad-c6ac41167942: the item does not exist anymore
> at org.apache.jackrabbit.core.ItemImpl.sanityCheck(ItemImpl.java:157)
> at org.apache.jackrabbit.core.NodeImpl.getParent(NodeImpl.java:1903)
> at
> at.onlaw.redsys.KommentarManager.replaceText(KommentarManager.java:479)
> at org.apache.jsp.editNE_jsp._jspService(editNE_jsp.java:94)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
