jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Created: (JCR-1549) XATest#testXAVersionsThoroughly fails if 2 checks are executed separately
Date Wed, 23 Apr 2008 10:49:21 GMT
XATest#testXAVersionsThoroughly fails if 2 checks are executed separately
-------------------------------------------------------------------------

                 Key: JCR-1549
                 URL: https://issues.apache.org/jira/browse/JCR-1549
             Project: Jackrabbit
          Issue Type: Bug
          Components: transactions, versioning
            Reporter: angela


i came across the following problem while testing the new security functionality:

XATest#testXAVersionsThoroughly failed on line 1253 upon check(v1_2, phase, "1.0", -1);
where v1_2 is a version that was removed without having the corresponding transaction committed.

what happens:

1) check(Version, String, String, int) relies on a RepositoryException being generated upon
Version.getName()
     in case of the removed Version.
2) Version.getSuccessors() is never executed if getName fails and thus the number of successors
is not
    determined at all.

changing the check method to be:

    /**
     * helper method for {@link #testXAVersionsThoroughly()}
     */
    private void check(Version v, String phase, String name, int numSucc) {
        String vName;
        try {
            vName = v.getName();
        } catch (RepositoryException e) {
            // node is invalid after remove
            vName = name;
        }
        int vSucc = -1;
        try {
            vSucc = v.getSuccessors().length;
        } catch (RepositoryException e) {
            // node is invalid after remove
        }
        assertEquals(phase + " Version Name", name, vName);
        assertEquals(phase + " Num Successors", numSucc, vSucc);
    }

i.e. separately retrieving the successors will cause the test to fail, since retrieving the
successors
is perfectly possible although the node has be rendered invalid.

related information:
i run into that problem due to a change with the DefaultAccessManager, which i changed to
use the caching-hierarchyManager present with the SessionItemStateManager. It turned out that
in that case Version.getName() didn't fail as expected since for reasons i ignore the cache
was either not cleared
properly OR the corresponding entry got re-added.



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