Hope this helps
https://issues.apache.org/jira/browse/JCR-1352
i'd say it's a slightly different story.
upon a LOCK request the simple.DavResourceImpl by default
makes an attempt to lock the node on the repository.
it does so by:
- test if a repository Node exists
- test if Node is mix:lockable
- if not try to add that mixin type to the node
- locking the node
but:
if no node exists (and webdav allows to create a lock
on non-existing resources, which is something JCR does
not allow) or if for whatever reason adding the mixin-type
fails
- the resource is locked without having a lock in
the repository (and their lock-token is generated
in a different way than the lock-tokens generated
by the JCR repository).
-> that's the reason for 2 different token types.
still:
- removing the lock should succeed in either case.
- if that doesn't it's a bug (for this see
https://issues.apache.org/jira/browse/JCR-1352)
angela
