Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 59079 invoked from network); 18 Dec 2006 09:56:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Dec 2006 09:56:32 -0000 Received: (qmail 39607 invoked by uid 500); 18 Dec 2006 09:56:29 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 39577 invoked by uid 500); 18 Dec 2006 09:56:29 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 39557 invoked by uid 99); 18 Dec 2006 09:56:29 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2006 01:56:29 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of dominique.pfister@gmail.com designates 64.233.162.227 as permitted sender) Received: from [64.233.162.227] (HELO nz-out-0506.google.com) (64.233.162.227) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2006 01:56:19 -0800 Received: by nz-out-0506.google.com with SMTP id s18so691406nze for ; Mon, 18 Dec 2006 01:55:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JsyVzU97JJ9zQm/Gwp8S8KrHgOYz0sy5ZKIJPz/pvKYVSOm/oDGA/4a5EXAVpSAKP2ibhwmGMJtlzCHJH+26M+txqPk2tV5UdDTItiTd+BamZhNnHPqaiH3mUSL75eDy+O5GmqBni/Zu/gjJ7DAsqHP2hOIyUVXkZIIERpgzNUc= Received: by 10.65.54.9 with SMTP id g9mr4467211qbk.1166435758397; Mon, 18 Dec 2006 01:55:58 -0800 (PST) Received: by 10.65.135.13 with HTTP; Mon, 18 Dec 2006 01:55:58 -0800 (PST) Message-ID: <66c10f230612180155g6de94c6cr5663fc2bfc5d03bf@mail.gmail.com> Date: Mon, 18 Dec 2006 10:55:58 +0100 From: "Dominique Pfister" Sender: dominique.pfister@gmail.com To: dev@jackrabbit.apache.org Subject: Re: AccessManager + CachingHierarchyManager problem In-Reply-To: <510143ac0612180134l71de3291ic1d3c3e297d90906@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45817185.5040305@systemone.at> <510143ac0612180134l71de3291ic1d3c3e297d90906@mail.gmail.com> X-Google-Sender-Auth: 0f1b3e618fbcaca3 X-Virus-Checked: Checked by ClamAV on apache.org Hi Roland > > the problem is, that when calling the methods of the > > CachingHierarchyManager the nodes i ask for will be cached in the > > idCache in a wrong state (i. e.: before actually reordering the elements). > > so if i want f.ex. delete the node b after reordering, the node will > > be looked up in the idCache. in the cache the index of node b is still 2 > > (actually it should be 3) and so the wrong node will be deleted! > > I'm not too familiar with the HierarchyManager and the PathMap > constructs, but I assume that the problem might be related to > orderBefore only modifying the state of the parent node. It could be > that the cache entries for the affected child nodes are not updated. The effect of reordering nodes should immediately be reflected in the CachingHierarchyManager and there are also unit tests verifying this. Can you provide us a simple, isolated test program that exhibits this erroneous behaviour? Kind regards Dominique