jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-768) Node.getPath() will corrupt the session
Date Tue, 27 Feb 2007 15:37:06 GMT

    [ 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
        } else if (provider.hasItemState(discarded.getId())) {
        } else {

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.

View raw message