Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.23 as permitted sender)
Message-ID: <4F351F66.3050004@gmx.de>
Date: Fri, 10 Feb 2012 14:45:10 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: users@jackrabbit.apache.org
CC: Jukka Zitting <jukka.zitting@gmail.com>
Subject: Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token
 [..]
References: <1117F8CD-04EF-46DF-A09F-A6B53A084BF2@pooteeweet.org>
 <4F34D7BB.3070507@gmx.de>
 <06CA6799-3613-4653-9957-55D8A4A31700@pooteeweet.org>
 <4F34DB4E.6010900@gmx.de>
 <CAOFYJNavW4u7kuZurS5QJfLzSF1Cqs6VV88qDn+YKKtBrd9jDg@mail.gmail.com>
 <4F3507DC.7070600@gmx.de>
 <CAOFYJNYWd0GH2fUTceKj3N7P4i27R3GPk82e6ityPnbGbbG_BQ@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNYWd0GH2fUTceKj3N7P4i27R3GPk82e6ityPnbGbbG_BQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2012-02-10 14:08, Jukka Zitting wrote:
> Hi,
>
> 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.

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