Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4A82F50A.4010604@tu-dortmund.de>
Date: Wed, 12 Aug 2009 18:59:54 +0200
From: Lars Michele <lars.michele@tu-dortmund.de>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: WebDAV ACLs referring to deleted principals
References: <24934748.post@talk.nabble.com>
In-Reply-To: <24934748.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Marian.
> In my alterAcl() method, I retrieve the current ACL by first calling
> AccessControlManager#getPolicies [1] to determine the resource's current
> ACL, and then, if it has none, AccessControlManager#getApplicablePolicies()
> [2] to find an empty ACL I can work with. The problems appear if the
> resource's ACL contains an entry for a principal which has since be deleted
> (we're using an LDAP server to manage our principals, so we have no control
> over who will when delete users), since in this case both methods will throw
> a NoSuchPrincipalException.
The problem seems to be related to
http://www.nabble.com/Re:-Problem-with-jackrabbit-user-deletion-p23235921.html

and is, afaik solved in Jackrabbit 1.6.0.

Have a look at
http://svn.apache.org/viewvc/jackrabbit/tags/1.6.0/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/security/authorization/acl/ACLTemplate.java?revision=802049

The NoSuchPrincipalException is catched and the principal is created on
the fly to be able to edit the ACL.

Regards,
Lars