On Thu, Nov 27, 2014 at 7:41 AM, Angela Schreiber <[email protected]> wrote:
> hi
>
> sure... that would also be an option... but i would be
> equally fine to extend the API with something like
>
> @CheckForNull
> <T> T getAuthorizable(@Nonnull String id, @Nonnull Class<T>
> authorizableClass)
> throws AuthorizableTypeException
that would be helpful as well.
but FWIU his problem is that he wants to create a new user (or group)
and does not want to do an extra check if the creation fails to figure
out, which type of authorizable existed. I assume his current code
does:
try {
createUser()
} catch (AuthorizableExistsExcetion e) {
Authorizable a = getAuthorizable();
if (a.isGroup()) {
throw new AuthorizableMismatchException();
}
throw e;
}
regards, toby
>
>
> that would be convenient as the expected type of the authorizable
> (user or group) is quite often known.
>
> @timothee, feel free to request an improvement in JIRA.
>
> kind regards
> angela
>
>
> On 26/11/14 19:02, "Tobias Bocanegra" <[email protected]> wrote:
>
>>Hi,
>>
>>On Wed, Nov 26, 2014 at 2:41 AM, Angela Schreiber <[email protected]>
>>wrote:
>>> Hi Timothee
>>>
>>> I don't see where this exception would be thrown during regular
>>> calls to the JR user management API.
>>>
>>> UserManager#getAuthorizable doesn't allow to pass a the desired
>>> type nor do specific methods exist to retrieve a user or group.
>>>
>>> So, I am not totally sure how this method fits into the current
>>> API.... IMO it would only make sense to have it if we at the same
>>> time introduce a new method like
>>>
>>> <T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
>>> throws AuthorizableTypeException
>>>
>>
>>I think Tim's problem is that he wants to either create a new user or
>>group, but the "opposite" authorizable with the same name already
>>exist.
>>
>>I think it's easiest to include a:
>> isUser() to the AuthorizableExistsException exception.
>>
>>so the code could test:
>>
>>try {
>> createUser(userId);
>>} catch (AuthorizableExistsException e) {
>> if (!e.isUser()) {
>> // group with 'userid' already exists
>> }
>>
>>regards, toby
>>
>>> or something similar.
>>>
>>> kind regards
>>> angela
>>>
>>>
>>>
>>> On 20/11/14 15:45, "Timothée Maret" <[email protected]> wrote:
>>>
>>>>Hi,
>>>>
>>>>
>>>>In a project, we have a utility method that allows to get or create an
>>>>authorizable of a given type (user or group).
>>>>In case the method can't return an authorizable of the required type
>>>>(for
>>>>instance when requiring a group with id = X and a user with id = X
>>>>already exists), then a
>>>>org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
>>>>thrown.
>>>>
>>>>
>>>>An AuthorizableExistsException does not precisely identify the root of
>>>>the error and maybe an exception of type AuthorizableMissmatchException
>>>>would be better.
>>>>Of course, we could add this exception in our project, however I
>>>>thinking
>>>>it would be best to avoid adding extension of the JCR APIs at a project
>>>>level.
>>>>Therefor, would it make sense to add the exception
>>>>
>>>>
>>>>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
>>>>
>>>>
>>>>to the Jackrabbit API ?
>>>>
>>>>
>>>>This exception would be thrown in any case (currently none in
>>>>Jackrabbit)
>>>>where Jackrabbit can't return an Authorisable of a given type.
>>>>
>>>>
>>>>Regards,
>>>>
>>>>
>>>>Timothee
>>>>
>>>
>