[
https://issues.apache.org/jira/browse/SLING-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841285#comment-13841285
]
Bertrand Delacretaz commented on SLING-3267:
--------------------------------------------
bq. IIUC, the key point of this issue is that right now, the contract of
ResourceDecorator is not met (returning a null resource is not interpreted the
same as returning the original resource).
Exactly. Rereading the ResourceDecorator javadocs I see that I missed the bit
that says "Returning null is considered the same as returning the original
resource". This definitely does not work as my new tests demonstrate, and
nobody ever complained about that so if handling null differently is useful
(which needs to be decided on list) I think we could do it.
bq. it would be "easier" if the ResourceIteratorDecorator could just skip
Resources which sling:resourceType is sling:nonexisting.
Not sure if that's easier, and that's also dependent on the "is
ResourceDecorator appropriate for frags" question anyway.
> ResourceDecorator returning null should cause Resources to be ignored
> ---------------------------------------------------------------------
>
> Key: SLING-3267
> URL: https://issues.apache.org/jira/browse/SLING-3267
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.0.6
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
> Priority: Minor
> Attachments: SLING-3267.patch
>
>
> The ResourceDecorator API's decorate(...) method javadocs currently specify
> that it can return null, but I don't think that's supported in a consistent
> way in the resource resolving process - returning null causes the resource
> resolver to supply a null Resource in some cases, which will probably cause
> NPEs downstream.
> The javadocs also say "If the service does not want to decorate the resource,
> it should return the original resource" which is consistent with how the
> resource resolver currently operates: returning null is clearly not a way of
> saying "do not decorate this resource".
> As we're discussing feature flags in Sling, we could clarify this behavior by
> specifying that a ResourceDecorator returning null causes the resource to be
> considered as non-existent, and making the corresponding (rather small)
> changes in the resource resolver code.
> As every Resource needs to go through the available ResourceDecorators, this
> is a simple way of making resources hideable based on feature flags. One then
> just needs to implement a ResourceDecorator that returns null when a Resource
> must be ignored.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
