Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of fmeschbe@gmail.com designates
 209.85.220.221 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=shw5fADmXO/WUnB7apfbm8o9JZGPS57OzBNMX6UgHzxMmb7C5+o14WZGg3VIGZPeNW
         KTdUF8rvjGIPM6DwfOh6Q+/CEEoeBQDRT5JVH7SipCG0f3rwvlo2vbiQEcdV6FF94Slu
         f2U55BOceHA7TDLqBwuLo35IPks9QWFe8U7P8=
Message-ID: <4B98D625.4060909@gmail.com>
Date: Thu, 11 Mar 2010 12:38:13 +0100
From: Felix Meschberger <fmeschbe@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.8pre) Gecko/20100120 Shredder/3.0.2pre
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: UserManager API strangeness (II)
References: <4B98CBB5.7090306@gmail.com> <4B98CECB.5000105@day.com>
In-Reply-To: <4B98CECB.5000105@day.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 11.03.2010 12:06, Angela Schreiber wrote:
> Felix Meschberger wrote:
>> Hi
>>
>> another thing striked me looking at the UserManager API: there are 4
>> create methods:
>>
>>    createGroup(Principal);
>>    createGroup(Principal, String);
>>    createUser(String userID, String password, Principal principal,
>>                     String intermediatePath);
>>    createUser(String userID, String password;
>>
>> I am missing a method
>>
>>    createGroup(String groupName);
>>
>> in this picture. Is there a reason to not have such a method ?
> 
> yes. what should that groupName reflect?
> if you expect this to be the displayName you should
> use 'setProperty' instead.
> if you expect this to be the ID -> for groups the
> ID is generated based on the principalName which the
> following valiation:
> 
> - principalName already present with another user/group
>   -> attempt to create a duplicate -> fails
> 
> - principalName collides with a UserID in those cases
>   where principalName != userID -> generation of a unique
>   id for the group since the principalName is valid
> 
> - all other cases: principalName is the same as the groupID.
> 

Thanks for the information.

For a hypothetical createGroup(String groupName) method, I would assume
this to behave similar as createUser(String userName, String password):
The groupName is used as the Group ID and a collision with an existing
Authorizable ID would be considered an error.

Regards
Felix