[ http://issues.apache.org/jira/browse/JCR-224?page=all ]

Jukka Zitting updated JCR-224:
------------------------------

    Fix Version: 1.0

> 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
>      Fix For: 1.0

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

Reply via email to