[
https://issues.apache.org/jira/browse/SLING-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-3483:
---------------------------------------
Description:
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.
was:
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.
> 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)
