[
https://issues.apache.org/jira/browse/JCR-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-3900:
--------------------------------
Summary: LockTest.testNodeLocked: incorrect assumption about when the lock
token can be returned (was: LockTest.testNodeLocked: incorrect assumptuin
about when the lock token can be returned)
> LockTest.testNodeLocked: incorrect assumption 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)
