Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-1549

XATest#testXAVersionsThoroughly fails if 2 checks are executed separately

    Details

    • Type: Bug Bug
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Labels:
      None

      Description

      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)

        Unknown macro: { 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.

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            angela
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development