On 2012-02-10 14:08, Jukka Zitting wrote:
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.
Right.
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.
Yes, but to do that the server code needs to be in control over the lock
token format (it can't rely on what kind of strings the repository
generates); only then it can detect which tokens are for session scoped
locks.
Can we do pick out just that part without affecting the externally
visible token format? If not, we might just as well consider
That would be a hack which I'd like to avoid.
backporting all of JCR-3209. Is there any known scenario where doing
so would break or confuse existing clients?
Well, only broken clients that may have been special-cases for the
jackrabbit server. Davex should be ok.
Best regards, Julian
