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 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 >
