jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothee Maret (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3191) Oak UserManager#getAuthorizable handles null and empty string differently than Jackrabbit
Date Mon, 10 Aug 2015 08:01:46 GMT

    [ https://issues.apache.org/jira/browse/OAK-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679747#comment-14679747
] 

Timothee Maret commented on OAK-3191:
-------------------------------------

bq. even today's solution complies with the API
I agree. The only folks that may experience this edge case slight difference in the implementation
are those moving customer code from Jackrabbit code to Oak.

bq. so one might argue that it's consistent to behave the same for getAuthorizable
I agree. 

It is seems like an implementation choice whether to limit the valid inputs for consistency
or have the implementation handle as much input as possible. Maybe not breaking Oak code (thus
keeping returning null)  and telling Jackrabbit->Oak migrators that there may be change
is the simplest :-).

> Oak UserManager#getAuthorizable handles null and empty string differently than Jackrabbit
> -----------------------------------------------------------------------------------------
>
>                 Key: OAK-3191
>                 URL: https://issues.apache.org/jira/browse/OAK-3191
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.3.2
>            Reporter: Timothee Maret
>            Assignee: angela
>            Priority: Minor
>         Attachments: OAK-3191.patch, OAK-3191.patch
>
>
> With Jackrabbit, the following API call
> {code}
> UserManager#getAuthorizable(String auth)
> {code}
> with either {{null}} or {{""}} used to throw
> {code}
> throw new IllegalArgumentException("Invalid authorizable name '" + id + "'");
> {code}
> With Oak UserManager, the same input does not throw an IAE, but instead return a {{null}}
value when providing {{""}} and throws a NPE when providing {{null}}.
> From my POV, it would be best to avoid throwing exceptions on those two cases. Indeed,
returning a {{null}} value is simpler for the API user and would comply with the API.
> If so, the implementation in case of {{null}} may be changed in order to swallow the
{{null}} value and the difference between Jackrabbit and Oak may be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message