[ http://issues.apache.org/jira/browse/JCR-533?page=all ]
Jukka Zitting updated JCR-533:
------------------------------
Fix Version/s: 1.1
Affects Version/s: 0.9
1.0
> a Node.lock() is very like a Node.setProperty().
No, not really. A "transient lock" makes no sense, you always want your locks
to affect all sessions. The lock properties on mix:lockable nodes are more like
metadata that gives you access to the current locking state of a node, not
something you'd modify directly using the normal Item API.
> 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.0.1, 0.9
> Environment: Ubuntu Dapper
> Reporter: Paco Avila
> Assigned To: Stefan Guggisberg
> Fix For: 1.1
>
> 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
