jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Karlstrøm (JIRA) <j...@apache.org>
Subject [jira] Updated: (JCR-768) Node.getPath() will corrupt the session
Date Tue, 27 Feb 2007 09:12:05 GMT

     [ 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.


Mime
View raw message