[
https://issues.apache.org/jira/browse/SLING-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593256#comment-13593256
]
Julian Sedding edited comment on SLING-2698 at 3/5/13 9:29 AM:
---------------------------------------------------------------
I like Carsten's idea of wrapping the ResourceResolver. This should allow to
fully control the resources provided by this resolver. I presume this could be
as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver, if so inclined. With the current ResourceDecorator approach,
we might run into situations like SLING-2739, however, if we can decorate the
ResourceResolver, we should have better control.
was (Author: jsedding):
I like Carsten's idea of wrapping the ResourceResolver. This should allow
to fully control the resources provided by this resolver. I presume this could
be as simple as adding a ResourceResolverCustomizer interface, that can be
implemented by client-code. In
ResourceResolverFactoryImpl#getResourceResolverInternal() all
ResourceResolverCustomizers will get given a chance to customize the
ResourceResolver in service.ranking order (by decorating it, exchanging it all
together, or anything else that people could come up with).
The interface could look like this:
{code:java}
/**
* Hook that can be implemented to intercept a ResourceResolver just after its
* creation in order to do any modifications on it, e.g. decorating it with
additional
* behavior.
*/
public interface ResourceResolverCustomizer {
/**
* This method allows modifying, decorating or exchanging a
resource-resolver
* immediately after its creation. It is guaranteed that the {@code
ResourceResolver}
* provided as an argument has not been used yet.
*/
public ResourceResolver customize(ResourceResolver resolver);
}
{code}
Given such a hook, the ResourceAccessGate could implement this hook and live in
its own bundle, thus decoupling it from the resourceresolver bundle and its
release-cycle.
In addition, a decorator-based approach probably allows for relatively easy
mocking and unit-testing.
I implemented a generic ResourceResolverWrapper a while ago, which makes sure
all its Resources are also wrapped. The implementation lacks some new methods,
but might help to implement such an approach. I'll attach it in case it's
useful.
Regarding the regexps, my concerns stem from a recent negative experience
(different software, similar scenario). I agree that regexps may be useful and
should be allowed in implementations of ResourceAccessGate. I would try,
however, to avoid using regexps in the ResourceAccessGateHandler. This should
allow efficient preselection of relevant ResourceAccessGates and still allows
for arbitrary flexibility.
Regarding unwrapping the Resource intentionally, I agree that that's a
non-issue. A developer may just as well retrieve an administrative
ResourceResolver, if so inclined. With the current ResourceDecorator approach,
we might run into situations like SLING-2739, however, if we can decorate the
ResourceResolver, we should have better control.
> 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
