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 11:34:59 UTC
[jira] Created: (JCR-1055) Incorrect node position after import
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"]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1055) Incorrect node position after import
Posted by "Marcus Kaar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519474 ]
Marcus Kaar commented on JCR-1055:
----------------------------------
WOW!
thats good to hear!
Thank you!
Marcus.
> 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
> Fix For: 1.4
>
>
> 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"]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1055) Incorrect node position after import
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg resolved JCR-1055.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.4
fixed in svn r565399
thanks for reporting this issue!
> 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
> Fix For: 1.4
>
>
> 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"]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1055) Incorrect node position after import
Posted by "Marcus Kaar (JIRA)" <ji...@apache.org>.
[ 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"]
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"]
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)
> 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"]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1055) Incorrect node position after import
Posted by "Marcus Kaar (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (JCR-1055) Incorrect node position after import
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-1055:
-------------------------------
Affects Version/s: 1.2.1
1.2.2
1.2.3
1.3.1
Fix Version/s: (was: 1.4)
1.3.2
Merged to the 1.3 branch in revision 577818.
> 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.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1
> Reporter: Marcus Kaar
> Fix For: 1.3.2
>
>
> 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"]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.