Hi, On Fri, Feb 10, 2012 at 1:04 PM, Julian Reschke <[email protected]> wrote: > On 2012-02-10 12:23, Jukka Zitting wrote: >> That said, the "Bad check digit" issue sounds like something that >> shouldn't have happened even before JCR-3209. Does it only occur with >> the WebDAV layer or can it be reproduced with a local Jackrabbit >> instance? Perhaps we can come up with a more focused fix for the 2.4 >> branch that doesn't change the externally visible lock token format >> like JCR-3209 does. > > No, the problem has been around since JCR 2.0, as far as I can tell.
If I understand correctly, the problem here is that the WebDAV layer (in 2.x, x <= 4) comes up with its own WedDAV lock tokens also for session-scoped JCR locks and tries to pass also those tokens to LockManager.addLockToken(). Which then obviously complains. > If it's worth fixing, the best way to fix it would be to align with trunk. > Please no diverging strategies! Agreed, though assuming the above description is correct, it seems like only the isForSessionScopedLock() part of JCR-3209 would be needed to fix this issue for 2.4 and earlier. Can we do pick out just that part without affecting the externally visible token format? If not, we might just as well consider backporting all of JCR-3209. Is there any known scenario where doing so would break or confuse existing clients? BR, Jukka Zitting
