[
https://issues.apache.org/jira/browse/SLING-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594494#comment-13594494
]
Mike Müller edited comment on SLING-2698 at 3/6/13 8:44 AM:
------------------------------------------------------------
As we accept the need for a simple solution which works over all resource
providers (file, bundle, etc.) and move forward, the question we should discuss
is the one mentioned above:
1) should the implementation be in the ResourceResolver bundle and therefore no
other extension points for the full implementation are needed
or
2) do we want to separate the implementation in a new bundle but need something
like the ResourceResolverDecorator
In the first case the only new service interface in the Sling core is the
ResourceAccessGate. No further extenstion points in the ResourceResolver are
exposed and the implementation is in my pov clean with no impact on
applications which does not use this new service.
In case 2) the code can be separated for the cost of another new service
interface which allows to wrap the ResourceResolver. The advantage would be
that if we ever have another ResourceResolver in the future, the implementation
of the ResourceAccessGate service does apply to this new resource resolver as
well.
Sorry, haven't seen the mail on the mailing list from Carsten, so lets discuss
there to get to a conclusion...
best regards
Mike
was (Author: mykee):
As we accept the need for a simple solution which works over all resource
providers (file, bundle, etc.) and move forward, the question we should discuss
is the one mentioned above:
1) should the implementation be in the ResourceResolver bundle and therefore no
other extension points for the full implementation are needed
or
2) do we want to separate the implementation in a new bundle but need something
like the ResourceResolverDecorator
In the first case the only new service interface in the Sling core is the
ResourceAccessGate. No further extenstion points in the ResourceResolver are
exposed and the implementation is in my pov clean with no impact on
applications which does not use this new service.
In case 2) the code can be separated for the cost of another new service
interface which allows to wrap the ResourceResolver. The advantage would be
that if we ever have another ResourceResolver in the future, the implementation
of the ResourceAccessGate service does apply to this new resource resolver as
well.
> Add a minimal resource access gate
> ----------------------------------
>
> Key: SLING-2698
> URL: https://issues.apache.org/jira/browse/SLING-2698
> Project: Sling
> Issue Type: New Feature
> Components: ResourceResolver
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Resource Resolver 1.1.0
>
> Attachments: resource-resolver-wrapper.patch
>
>
> Adding a minmal resource access gate as discussed in [1].
> First step is to define the API interface and a minimal implementation which
> allows to define READ access (rest of CRUD can follow later)
> [1] http://markmail.org/thread/4ctczoiy533tquyl
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
