Bertrand Delacretaz created SLING-3483:
------------------------------------------
Summary: 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:
{code}
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);
}
{code}
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)
