You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcus Kaar (JIRA)" <ji...@apache.org> on 2007/08/08 12:18:59 UTC
[jira] Updated: (JCR-1055) Incorrect node position after import
[ 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.