[jira] [Resolved] (SLING-3483) Remove sling:features support from the resource resolver, for now

["Bertrand Delacretaz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bertrand Delacretaz resolved SLING-3483.
----------------------------------------

    Resolution: Fixed

sling:features support removed http://svn.apache.org/r1582243

> Remove sling:features support from the resource resolver, for now
> -----------------------------------------------------------------
>
>                 Key: SLING-3483
>                 URL: https://issues.apache.org/jira/browse/SLING-3483
>             Project: Sling
>          Issue Type: Improvement
>          Components: ResourceResolver
>    Affects Versions: Resource Resolver 1.0.6
>            Reporter: Bertrand Delacretaz
>            Assignee: Bertrand Delacretaz
>            Priority: Minor
>
> As discussed on list ( http://markmail.org/message/nuaiox2gkmutttdo ) I believe the current "magic" support of the sling:features resource property in the resource resolver core opens a can of worms in some cases. Carsten agrees and we'd like to remove that support from the core resource resolver bundle for now.
> [~justinedelson] was not fully convinced of removing it in that discussion, but AFAICS he agrees about moving that functionality to a separate bundle that we can then clearly label as experimental.
> In the current code, the decision to hide a resource based on feature flags is done in a single place, in the ProviderHandler class:
> Resource getReadableResource ( final ResourceResolverContext ctx, ...){
>   Resource returnValue = null;
>   ...set returnValue unless resourceAccessSecurity objects...
>   ...and now ctx can decide to hide the resource based on sling:features
>   return ctx.applyFeatures(returnValue);
>     }
> So using a service implemented in a different bundle is not a problem, it would just be used instead of (or inside) the ResourceResolverContext. That service only needs to know about the Resource and the features services, it doesn't need any internal knowledge of the resource resolver state.
> For now I'll go ahead and remove the sling:features support from the resourceresolver bundle, and we can later experiment and re-add it with a more modular design.



--
This message was sent by Atlassian JIRA
(v6.2#6252)