You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@gmail.com> on 2010/03/11 11:53:41 UTC

UserManager API strangeness (II)

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 ?

Thanks and Regards
Felix

Re: UserManager API strangeness (II)

Posted by Angela Schreiber <an...@day.com>.

Felix Meschberger wrote:
> I created JCR-2563 [1] with a proposed patch adding said
> createGroup(String) method.
> 
> Anyway opposed to me applying this patch ?

i want to take a look at it first and will apply it myself
if i feel comfortable with the patch.

thanks
angela

> Regards
> Felix
> 
> [1] https://issues.apache.org/jira/browse/JCR-2563
> 
> On 11.03.2010 12:38, Felix Meschberger wrote:
>> 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
>

Re: UserManager API strangeness (II)

Posted by Felix Meschberger <fm...@gmail.com>.

I created JCR-2563 [1] with a proposed patch adding said
createGroup(String) method.

Anyway opposed to me applying this patch ?

Regards
Felix

[1] https://issues.apache.org/jira/browse/JCR-2563

On 11.03.2010 12:38, Felix Meschberger wrote:
> 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

Re: UserManager API strangeness (II)

Posted by Felix Meschberger <fm...@gmail.com>.

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

Re: UserManager API strangeness (II)

Posted by Angela Schreiber <an...@day.com>.

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.

hope that helps.
angela