Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.22 as permitted sender)
Message-ID: <4F3507DC.7070600@gmx.de>
Date: Fri, 10 Feb 2012 13:04:44 +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>
In-Reply-To: 
 <CAOFYJNavW4u7kuZurS5QJfLzSF1Cqs6VV88qDn+YKKtBrd9jDg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2012-02-10 12:23, Jukka Zitting wrote:
> Hi,
>
> On Fri, Feb 10, 2012 at 9:54 AM, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> Should we port *every* fix back? (not a rhetorical question).
>
> Only those that people are asking for (or that we can assume people to
> run into). Additionally, we should ideally only backport low-risk bug
> fixes, not wider improvements or other more risky changes. The main
> focus in a maintenance branch like 2.4 is stability so upgrading from
> 2.4.x to 2.4.(x+1) should never break anything, which limits the
> amount and type of changes that should be backported.
>
> On this specific issue, the mentioned JCR-3209 is a little bit broader
> change that modifies the way lock tokens are handled by the WebDAV
> layer. Thus I'd rather keep it out of the 2.4 branch now that 2.4.0 is
> already out.
>
> 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 it's worth fixing, the best way to fix it would be to align with 
trunk. Please no diverging strategies!

Best regards, Julian