Hi all,
In SLING-909 [1] and SLING-752 [2] an API inconsistency has been uncovered.
(1) Intent:
ResourceResolver.getResource methods return null if the
requested resource cannot be found
ResourceResolver.resolve methods return NonExistingResource
if the requested resource cannot be found
(2) Reality:
ResourceResolver.resolve(String path) returns null if the
requested resource cannot be found
All other methods behave as intended.
To fix the "wrong" resolve(String) method now would mean to break
backwards compatibility with the released version of both the Sling API
and the actual implementation in the jcr.resource bundle.
In the mail thread accompanying SLING-752 [3] we decided to value
backwards compatibility higher than consistency and correctness.
Therefore we kept the resolve(String) method in the wrong implemenation,
though the API document currently documents the "correct" behaviour,
which is not what has been decided.
I am not sure, what the correct behaviour really is, therefore, I would
like to repoen this discussion again (for the last time, I promise).
Do we want to keep the ResourceResolver.resolve(String path) method
return null if the reource cannot be found (backwards compatible case)
or do we want to have the method return NonExistingResource (consistency
case).
I myself am undecided, though I tend to favour the consistency case.
WDYT?
Regards
Felix
[1] https://issues.apache.org/jira/browse/SLING-909
[2] https://issues.apache.org/jira/browse/SLING-752
[3] http://markmail.org/message/ulqwzjilp6prq75m
Felix Meschberger (JIRA) schrieb:
> [
> https://issues.apache.org/jira/browse/SLING-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695253#action_12695253
> ]
>
> Felix Meschberger commented on SLING-909:
> -----------------------------------------
>
> Absolutely true, but ... As the mail thread accompanying SLING-752 indicates,
> we had the inconsistency in the first Sling release. And yes, this was a bug
> and yes it would be better to fix it.
>
> But, at that time (sorry to repeat myself), we decided to stay backwards
> compatible with the released API/implementation.
>
>> 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).
>
