You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Frank Karlstrøm (JIRA)" <ji...@apache.org> on 2007/02/26 22:42:05 UTC
[jira] Created: (JCR-768) Node.getPath() will make the corrupt the
session
Node.getPath() will make the corrupt the session
------------------------------------------------
Key: JCR-768
URL: https://issues.apache.org/jira/browse/JCR-768
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.2.2, 1.2.1, 1.1.1, 1.1
Environment: JDK 1.5, WinXP
Reporter: Frank Karlstrøm
Priority: Critical
When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes. The attached test will fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-768) Node.getPath() will make the corrupt the
session
Posted by "Frank Karlstrøm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Karlstrøm updated JCR-768:
--------------------------------
Attachment: JackRabbitBugTest.java
This test will fail on all versions of jackrabbit except for 1.0 and 1.0.1
> Node.getPath() will make the corrupt the session
> ------------------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Priority: Critical
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-768) Node.getPath() will corrupt the session
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg updated JCR-768:
----------------------------------
Priority: Major (was: Critical)
not critical since there's no real data corruption. it's the session's view that gets corrupted. still a major issue though.
> Node.getPath() will corrupt the session
> ---------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Assigned To: Stefan Guggisberg
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a javax.jcr.RepositoryException: /: cannot remove root node.
> We have seen other configurations where a node suddenly behaves as the another node that has references and throw a reference exception, and yet other configurations where the node we though we deleted still exists, and another node has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-768) Node.getPath() will corrupt the session
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg resolved JCR-768.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.2.3
fixed as dominique suggested (svn r512296)
> Node.getPath() will corrupt the session
> ---------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Assigned To: Stefan Guggisberg
> Fix For: 1.2.3
>
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a javax.jcr.RepositoryException: /: cannot remove root node.
> We have seen other configurations where a node suddenly behaves as the another node that has references and throw a reference exception, and yet other configurations where the node we though we deleted still exists, and another node has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-768) Node.getPath() will make the corrupt the
session
Posted by "Frank Karlstrøm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Karlstrøm updated JCR-768:
--------------------------------
Description:
When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
The attached test will always fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
Have also tested the latest release: 1.2.2, and the bug is still present there.
was:
When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes. The attached test will fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
Have also tested the latest release: 1.2.2, and the bug is still present there.
> Node.getPath() will make the corrupt the session
> ------------------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Priority: Critical
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-768) Node.getPath() will corrupt the session
Posted by "Frank Karlstrøm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Karlstrøm updated JCR-768:
--------------------------------
Description:
When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
The attached test will always fail with a javax.jcr.RepositoryException: /: cannot remove root node.
We have seen other configurations where a node suddenly behaves as the another node that has references and throw a reference exception, and yet other configurations where the node we though we deleted still exists, and another node has now disappeared.
I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
Have also tested the latest release: 1.2.2, and the bug is still present there.
was:
When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
The attached test will always fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
Have also tested the latest release: 1.2.2, and the bug is still present there.
This test in fact fails with a root node deletion exception, wrong description in initial bug report:
javax.jcr.RepositoryException: /: cannot remove root node
at org.apache.jackrabbit.core.ItemImpl.internalRemove(ItemImpl.java:821)
at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:1049)
at com.bug.app.JackrabbitBugTest.testDelete(JackrabbitBugTest.java:30)
> Node.getPath() will corrupt the session
> ---------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Priority: Critical
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a javax.jcr.RepositoryException: /: cannot remove root node.
> We have seen other configurations where a node suddenly behaves as the another node that has references and throw a reference exception, and yet other configurations where the node we though we deleted still exists, and another node has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-768) Node.getPath() will corrupt the session
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476198 ]
Dominique Pfister commented on JCR-768:
---------------------------------------
Looks like the CachingHierarchyManager gets a discard on the parent item (named aNode in the unit test) after having saved the removal of the child node. Inside its stateDiscarded(ItemState) implementation, it sees no overlayed state on this item, and therefore assumes that this parent node no longer exists:
--> if (discarded.isTransient() && !discarded.hasOverlayedState()) {
// a new node has been discarded -> remove from cache
remove(discarded.getId());
} else if (provider.hasItemState(discarded.getId())) {
evict(discarded.getId());
} else {
remove(discarded.getId());
}
The overlayed state, however, has been disconnected in the node's makePersistent. The check above should additionally test, whether the item's state is new:
if (discarded.isTransient() && !discarded.hasOverlayedState() &&
--> discarded.getStatus() == ItemState.STATUS_NEW) {
...
}
With this patch, the test runs without errors.
> Node.getPath() will corrupt the session
> ---------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Assigned To: Stefan Guggisberg
> Priority: Critical
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a javax.jcr.RepositoryException: /: cannot remove root node.
> We have seen other configurations where a node suddenly behaves as the another node that has references and throw a reference exception, and yet other configurations where the node we though we deleted still exists, and another node has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-768) Node.getPath() will corrupt the session
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Guggisberg reassigned JCR-768:
-------------------------------------
Assignee: Stefan Guggisberg
> Node.getPath() will corrupt the session
> ---------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Assigned To: Stefan Guggisberg
> Priority: Critical
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a javax.jcr.RepositoryException: /: cannot remove root node.
> We have seen other configurations where a node suddenly behaves as the another node that has references and throw a reference exception, and yet other configurations where the node we though we deleted still exists, and another node has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-768) Node.getPath() will corrupt the session
Posted by "Frank Karlstrøm (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Karlstrøm updated JCR-768:
--------------------------------
Summary: Node.getPath() will corrupt the session (was: Node.getPath() will make the corrupt the session)
> Node.getPath() will corrupt the session
> ---------------------------------------
>
> Key: JCR-768
> URL: https://issues.apache.org/jira/browse/JCR-768
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
> Environment: JDK 1.5, WinXP
> Reporter: Frank Karlstrøm
> Priority: Critical
> Attachments: JackRabbitBugTest.java
>
>
> When calling Node.getPath() anytime, no mather if its before or after save, and when deleting nodes, the internal reference points to the wrong nodes.
> The attached test will always fail with a reference exception. We have seen other configurations where a node suddenly behaves as the root node, and yet other configurations where the node we though we deleted still exists, and another noe has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.