[ http://issues.apache.org/jira/browse/JCR-224?page=comments#action_12330589 ]
angela commented on JCR-224: ---------------------------- you don't remember that discussion, because it took place before it was decided that you are going to implement the locking... i'm afraid too :)). and: it's not clear to me from the spec v. 1.0, that it must work the way it works. i couldn't find a section that says, that only one session can be a lockholder at one time. that's way i'm posting that issue. but maybe i was just blind :)). kind regards angela ps: it might also be that for whatever reason this is simply not possibly. but then the spec should say so clearly from my point of view. to me it seemed obvious, that there would not be a public method addLockToken(String) if not for this exact reason... > Lock: Session.addLockToken(String) does make the session to a lock holder > ------------------------------------------------------------------------- > > Key: JCR-224 > URL: http://issues.apache.org/jira/browse/JCR-224 > Project: Jackrabbit > Type: Bug > Components: locks > Reporter: angela > > JSR170 says: > Lock.getLockToken(): > "May return the lock token for this lock. If this Session holds the lock > token for this lock, then this method will return that lock token. If this > Session does not hold the applicable lock token then this method will return > null." > Session.addLockToken(String lt): > "Adds the specified lock token to this session. Holding a lock token allows > the Session object of the lock owner to alter nodes that are locked by the > lock specified by that particular lock token." > and: > "Note that, as mentioned above, any user with the correct lock token assumes > the power to remove a lock and alter nodes under that lock. It does not have > to be the lock owner." > If i remember the discussion regarding the locking correctly, it was decided, > that the locktoken is turned to any session, that contains the proper token. > And: the Lock.getLockToken() is the only way to find out, whether a given > session is allowed to modify a locked node (in contrast to the isLocked() > method). > I have the impression, that the current implementation does not respect this: > Lock.getLockToken() passes the call to the LockInfo object. The latter > performs the following check: > public String getLockToken(Session session) { > if (session.equals(lockHolder)) { > return lockToken.toString(); > } > return null; > } > where the lockHolder is set to a particular session in consequence to > Session.addLockToken but only if the lockHolder is null... otherwise the call > it is ignored (LockManagerImpl line 468). > however, from the above quotes, i would rather expect, that the method should > check, if the given Session holds the lockToken associated with this lock. > regards > angela -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
