jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]
Date Fri, 10 Feb 2012 13:08:31 GMT

On Fri, Feb 10, 2012 at 1:04 PM, Julian Reschke <julian.reschke@gmx.de> 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?


Jukka Zitting

View raw message