Julian Reschke wrote:
I would be sufficient to keep the lock *token*, and to re-attach it to the current session for the purpose of discovering locks (and only that purpose).
what do you mean by current session? as long as you don't keep the sessions on the server you get a new one.... to which do you then put the tokens? how do you determine the lock-holder? the Session.getUserID is for information purpose only and so is the Lock.getOwner() defined in the jcr-api. i wouldn't want to rely on any of those. and you wouldn't want to put the tokens to any session, do you?
In general, we have several mismatches between JCR locking and WebDAV locking. If we can't fix them, we probably should document them.
fine with me... feel free to extend the docu or write something to the wiki.
In this case, the (IMHO) right fix would be to allow a JCR server to return the lock token even when it is *not* attached to the session (or to define an alternate way to get hold of the token).
not sure, whether i agree on this. what do you do with lock, that have not been applied via webdav (but by other ways to access the jcr-repo)? you won't have a token then... i would consider this to be a workaround (and prone to cause strange errors).... not sure, if this is the best way to go. at least i wouldn't call this 'the right fix'. specially if it's there to work around misbehaving clients. angela
