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)