Hi,
as recent discussion showed, there might be use cases for a resource
provider decorator. A decorator can be used to add functionality
across several resource providers. E.g. this would simplify securing
resource providers which don't support access checks ootb, like the
file resource provider or the MongoDB resource provider.
Decorating a resource provider is not as trivial as decorating a
resource because a provider might come in different flavours =
implement additional functionality through sub interfaces.
So I think just having a single decorate method is too error-prone as
the implementation would have to check whether a resource provider
implements those interfaces and construct a corresponding resource
provider.
Therefore I propose we add a simple interface:
public interface ResourceProviderDecorator {
ResourceProvider decorate(final ResourceProvider provider);
AttributableResourceProvider decorate(final
AttributableResourceProvider provider);
ModifyingResourceProvider decorate(final ModifyingResourceProvider
provider);
QueriableResourceProvider decorate(final QueriableResourceProvider
provider);
DynamicResourceProvider decorate(final DynamicResourceProvider provider);
}
which allows to decorate each separately. At the same time we add
wrapper implementations for all of the above which delegate to the
passed in resource provider. This makes the implementation much
easier.
The decorators are ordered by their service ranking and called in this order.
WDYT?
Regards
Carsten
--
Carsten Ziegeler
[email protected]
