jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-1549) XATest#testXAVersionsThoroughly fails if 2 checks are executed separately
Date Fri, 17 Oct 2008 10:41:44 GMT

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

Jukka Zitting updated JCR-1549:
-------------------------------

    Component/s: jackrabbit-core

> 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: jackrabbit-core, transactions, versioning
>    Affects Versions: 1.5.0
>            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.


Mime
View raw message