Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-3900

LockTest.testNodeLocked: incorrect assumption about when the lock token can be returned

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.10.1, 2.8.1, 2.11.0
    • 2.10.2, 2.8.2, 2.11.1
    • test
    • None

    Description

      testNodeLocked contains:

                  // get same node
                  Node n2 = (Node) otherSuperuser.getItem(n1.getPath());
      
                  // assert: lock token must be null for other session
                  assertNull("Lock token must be null for other session",
                          n2.getLock().getLockToken());
      

      However, the spec says in <http://www.day.com/specs/jcr/2.0/17_Locking.html#17.11.7%20Getting%20Lock%20Tokens>:

      "String Lock.getLockToken()

      may return the lock token for this lock. If this lock is open-scoped and the current session holds the lock token for this lock, then this method will return that lock token. If the lock is open-scoped and the current session does not hold the lock token, it may return the lock token. Otherwise this method will return null."

      ...so returning the lock is ok here for open-scoped locks (and this is what oak-jcr does thus fails this test).

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            reschke Julian Reschke
            reschke Julian Reschke
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment