[
https://issues.apache.org/jira/browse/SLING-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695075#action_12695075
]
Felix Meschberger commented on SLING-909:
-----------------------------------------
For the short term, just call the resolve(HttpServletRequest, String) method as
resolve(null, path)
Rereading SLING-752 resolves into saying, that backwards compatibility is more
important than consistency. Do we want to reconsider this ?
> 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.
