Explicit multi-tenancy support in @ResourceModels

[SebastianLisken]

Sometimes, particularly in a multi-tenant setup, it would be helpful if the @ResourceModel annotation could be made to apply only to some subtree in the content hierarchy. This could eliminate some problems with "competing" resource models that apply to the same resource type.

I envisage specifying an arbitrary number of Strings or even Patterns either as a "paths" parameter in the @ResourceModel annotation or in an extra annotation that can be combined with @ResourceModel. For the Strings, the method to check whether the criterion succeeds must not simply be "startsWith" but rather the one used in PagePathUtils.isPagePathInSubtree(String, String) [from the CQ Foundation library which is not part of this repository]. For Patterns, the code to decide wether a path matches would probably have to be something like this:

Matcher matcher = pattern.matcher(resourcePath);
boolean criterionMet;
if (matcher.lookingAt()) {
     if (matcher.end() <= 1) {
        criterionMet = true; // the pattern matched "" or "/"
     } else if (matcher.end() == resourcePath.length() || resourcePath.charAt(matcher.end()) == '/') {
        criterionMet = true; // the full path was matched, or the path continues with "/"
     } else {
        criterionMet = false;
     }
 } else {
    criterionMet = false;
 }

[DaniRey]

I think this should not be implemented because of two reasons.

1. It would make reasoning about matching Resource Models complex and error prone.
2. I don't see why this should be needed. If a multi-tenant project requires different resource models for different resources, those resources should simply use different ResourceTypes.

[olaf-otto]

I agree with 1 - it will make matching significantly more complex. However, I definetly see valid cases for 2, for instance deviating models for common resource types such as nt:base or AEM specific types such as dam:Asset, cq:Page or cq:PageContent.

I am wondering whether we could make at an explicit "tenant" feature out of this to simplify the resolution, something like

@Tenant("id"...)

And somehow map this to Sling's tenant support or some configuration of the form

tenantId -> root paths

See also https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support - we'd have to investigate the progress there first...

[olaf-otto]

Hi @DaniRey, could you have a quick look at the state of the Sling multi-tenancy support shipped with AEM 6.1?

[olaf-otto]

I am closing this as won't fix. We'll get back to this once programmatic multi-tenancy in sling is mature.