[
https://issues.apache.org/jira/browse/SLING-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695312#action_12695312
]
Alexander Klimetschek commented on SLING-909:
---------------------------------------------
But at least the javadoc has to be fixed if the return-null feature has to be
in there for backwards compatability.
Other ideas:
- break backwards compat for the jcrresourceresolver2 as it is new anyway (my
favorite; and it is not part of any official sling release, is it?)
- make the current behaviour (return-null) deprecated and switch to correct api
implementation soon
WDYT?
> JcrResourceResolver2.resolve returns null for non-existing resources while
> api doc says otherwise
> -------------------------------------------------------------------------------------------------
>
> Key: SLING-909
> URL: https://issues.apache.org/jira/browse/SLING-909
> Project: Sling
> Issue Type: Bug
> Components: JCR Resource
> Reporter: Alexander Klimetschek
>
> (This is a basically a re-opening of SLING-752, because I don't have rights
> to reopen that bug).
> In current trunk, although to be said to be fixed with SLING-752, the API doc
> of ResourceResolver.resolve(String) says:
> * @return The {...@link Resource} addressed by the <code>absPath</code>
> or a
> * {...@link NonExistingResource} if no such resource can be
> resolved.
> The implementation of this method in JcrResourceResolver2 however will return
> null (it calls resolveInternal() with requireResource=false).
> I have a use case where I don't have a request object (running in an event
> job) but still like to get a NonExistingResource, not null. Therefore I'd
> suggest to change JcrResourceResolver2.resolve() to not return null (and keep
> the javadoc).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
