[
http://issues.apache.org/jira/browse/GRFT-73?page=comments#action_12357589 ]
Martin Koci commented on GRFT-73:
---------------------------------
LockingException serves as root exception for all errors related to locking.
Simple instanceof checking can say "something wrong with locking". For example
I have LockingExceptionHandler which translates exceptions to user-friendly
messages:
public class LockExceptionHanlder {
boolean canHandle(Exception e) {
return e instanceof LockingException;
}
// ... translation: ex type to mesage here
}
In future this type can hold common attributes for all locking exception, e.g.
userID (who cannot do something with locked node)
> Check locked node status in operations
> --------------------------------------
>
> Key: GRFT-73
> URL: http://issues.apache.org/jira/browse/GRFT-73
> Project: Graffito
> Type: Improvement
> Components: JCR-Mapping
> Versions: 1.0-a1-dev
> Reporter: Martin Koci
> Assignee: Christophe Lombart
> Priority: Critical
> Fix For: 1.0-a1-dev
> Attachments: CannotUnlockException.java, LockedException.java,
> LockingException.java
>
> Many operations on Node throws LockException if node is locked. But current
> code doesnt reflect this behaviour correctly: e.g. checkin:
> try{
> Node node = (Node) session.getItem(path);
> ...
> javax.jcr.version.Version newVersion = node.checkin();
> // throws LockException if node locked
> ....
> }catch (RepositoryException e) { // Catch LockException too !!
> throw new VersionException("Impossible to checkin the
> object " + path, e);
> }
> LockException -> VersionException?
--
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
