jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paco Avila (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-533) failing Node.lock() might leave inconsistent transient state
Date Fri, 11 Aug 2006 10:46:17 GMT
    [ http://issues.apache.org/jira/browse/JCR-533?page=comments#action_12427499 ] 
            
Paco Avila commented on JCR-533:
--------------------------------

Ok, the specification is clear about Node.lock() and says that it is not neccesary to call
a Node.save(). I know. But I don't know why the specification writers did this decission:
a Node.lock() is very like a Node.setProperty(). Do you know what I mean? Obvious Jackrabbit
is an implementatio of this especification and must follow it. 

I think I can close the issue, isn't it?

> failing Node.lock() might leave inconsistent transient state
> ------------------------------------------------------------
>
>                 Key: JCR-533
>                 URL: http://issues.apache.org/jira/browse/JCR-533
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: locks
>    Affects Versions: 1.0.1
>         Environment: Ubuntu Dapper
>            Reporter: Paco Avila
>         Assigned To: Stefan Guggisberg
>         Attachments: DummyLockAccessDenied.java, MyAccessManagerLockAccessDenied.java
>
>
> When I try to node.lock(true, false) a node and the lock fails due to lak of user privilegies,
the lock stay in the user transient session. If a perform a node.refresh(false) the node still
is locked in the transient session.

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

        

Mime
View raw message