Hi, I have opened [0,1] and attached a patch (Angela’s solution).
Regards, Timothee [0] https://issues.apache.org/jira/browse/JCR-3836 [1] https://issues.apache.org/jira/browse/JCR-3837 On 04/12/14 13:13, "Timothee Maret" <[email protected]> wrote: >Hi Angela and Toby, > >Thanks for your input. My mail client missed your replies, thus answering >only now. >The utility methods (users and groups) we want to implement have >signatures similar to the one below: > >/** > * This method get or create the required group using the provided {@link >UserManager} user manager. > * This method does not save changes to the user manager session. > * > * @param userManager the {@link UserManager} used to access or create the >group > * @param intermediatePath parent path where the group should be created > * @param groupId the group identifier to be accessed/created > * @return the existing or new {@link Group} > * @throws AuthorizableMismatchException if an {@link Authorizable} does >exist but is not a {@link Group} > */ >Group getOrCreateGroup(UserManager userManager, String intermediatePath, >String groupId) > throws RepositoryException; > >The AuthorizableMismatchException extending RepositoryException. > > >The implementation goes as follow > >Auth auth = getAuthorizable() >If (auth is null) { > return createGroup() >} else if (auth not a group) { > throw AuthorizableMismatchException >} else return auth > >I think it would be great to have Angela¹s suggestion regarding allowing >to specify the type when we get an Authorizable. >However, since the set of possible Authorizable is fixed and limited, we >may have a specific method for each type. > >Group getGroup(@Nonnull String id) throws AuthorizableTypeException >User getUser(@Nonnull String id) throws AuthorizableTypeException > > > >The other approach (passing the type in the exception) would work fine as >well. > >I¹ll JIRA an attach a patch. > >Regards, > >Timothee > > > > >On 28/11/14 02:39, "Tobias Bocanegra" <[email protected]> wrote: > >>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.AuthorizableMissmatchExceptio >>>>>>n >>>>>> >>>>>> >>>>>>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 >>>>>> >>>>> >>> >
