[jira] Updated: (JCR-1549) XATest#testXAVersionsThoroughly fails if 2 checks are executed separately

["angela (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

angela updated JCR-1549:
------------------------

    Attachment: JCR-1549.diff

suggested fix of the test case (will then cause the test to fail)

> 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
>         Attachments: JCR-1549.diff
>
>
> 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.