You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (JIRA)" <ji...@apache.org> on 2015/08/20 14:39:45 UTC

[jira] [Created] (JCR-3900) LockTest.testNodeLocked: incorrect assumptuin about when the lock token can be returned

Julian Reschke created JCR-3900:
-----------------------------------

             Summary: LockTest.testNodeLocked: incorrect assumptuin about when the lock token can be returned
                 Key: JCR-3900
                 URL: https://issues.apache.org/jira/browse/JCR-3900
             Project: Jackrabbit Content Repository
          Issue Type: Improvement
          Components: test
    Affects Versions: 2.11.0
            Reporter: Julian Reschke
            Assignee: Julian Reschke


testNodeLocked contains:

{code}
            // 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());
{code}

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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)