[servlets] SLING-8170 - Allow Sling servlets to declare a resource super type

[Radu Cotescu <ra...@apache.org>]

Hi,

I’ve recently opened 2 PRs for Apache Sling API and Apache Sling Servlets Resolver. The goal is the ability to define a way to overlay servlets / delegate to other servlets at runtime [0], similar to what’s already available for scripts. Besides the overlaying functionality, this will allow bundled scripts (optionally precompiled) to be able to delegate rendering to pre-existing servlets / scripts that are not necessarily registered through the new Apache Sling Scripting Bundle Tracker [1].

Please let me know what you think.

Regards,
Radu

[0] - https://issues.apache.org/jira/browse/SLING-8170 <https://issues.apache.org/jira/browse/SLING-8170>
[1] - https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker <https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker>

Re: [servlets] SLING-8170 - Allow Sling servlets to declare a resource super type

[Radu Cotescu <ra...@apache.org>]

Hi Konrad,

> On 11 Dec 2018, at 19:11, Konrad Windszus <ko...@gmx.de> wrote:
> 
> I am not sure I do understand 100% your use case:
> How are you supposed to do request dispatching to another servlet then? Only in case request dispatching is used I see an actual benefit (to only overwrite one part of a servlet but not another). There you would need to rely on selectors (instead of the script name), right? Maybe you can give a concrete example on where you think inheritance of servlets would be useful.
> Or is your use case more in the AEM area where dialogs, component definitions, ... could be reused?

The use-case is mainly related to the new Bundle Tracker [1] which Karl and I presented at adaptTo 2018. In this project a Provided Capability identifying a certain resource type will generate a servlet registration. While the whole provide / require mechanism would allow creating a dependency chain, it would not allow such a bundled scripting component to extended a previously existing component, defined using scripts in content. On top of that, a bundled scripting component would also not be able to reuse previously existing servlets in order to delegate rendering.

One such example that’s public is the AdaptiveImageServlet [2] from the Core Components project. Assuming one would repack the Core Components to use only precompiled bundled scripts, there would be no way a proxy image component would be able to extend the “core/wcm/components/image” resource type to reuse the servlet [2] for resizing the asset.

The change I propose just brings servlets on parity with scripts in terms of inheritance / runtime delegation. Check another example at [3]. Here you have two servlets, One and Two. One is bound to “my/servlet/html.servlet”, whereas Two is bound to “another/servlet/sel.html.servlet”. Assume the following two resources:

/content/test-1 [sling:resourceType=my/servlet]
/content/test-2 [sling:resourceType=another/servlet]

GET /content/test-1.html would be rendered by One
GET /content/test-2.html would be rendered by the DefaultGetServlet, assuming we don’t have support for “sling.servlet.resourceSuperType”
GET /content/test-2.sel.html would be rendered by Two

Assuming support for “sling.servlet.resourceSuperType”, the previous requests would look like:
GET /content/test-1.html would be rendered by One
GET /content/test-2.html would be rendered by One, since “another/servlet” has a sling:resourceSuperType=my/servlet
GET /content/test-2.sel.html would be rendered by Two

I hope this makes things clearer and properly explains the use-cases.

Thanks,
Radu

[2] - https://github.com/adobe/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java <https://github.com/adobe/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/servlets/AdaptiveImageServlet.java>
[3] - https://gist.github.com/raducotescu/41b1b6555b75d7089186b2e3708c2817 <https://gist.github.com/raducotescu/41b1b6555b75d7089186b2e3708c2817>

Re: [servlets] SLING-8170 - Allow Sling servlets to declare a resource super type

[Konrad Windszus <ko...@gmx.de>]

I am not sure I do understand 100% your use case:
How are you supposed to do request dispatching to another servlet then? Only in case request dispatching is used I see an actual benefit (to only overwrite one part of a servlet but not another). There you would need to rely on selectors (instead of the script name), right? Maybe you can give a concrete example on where you think inheritance of servlets would be useful.
Or is your use case more in the AEM area where dialogs, component definitions, ... could be reused?

Thanks,
Konrad



> On 11. Dec 2018, at 14:58, Radu Cotescu <ra...@apache.org> wrote:
> 
> Hi,
> 
> I’ve recently opened 2 PRs for Apache Sling API and Apache Sling Servlets Resolver. The goal is the ability to define a way to overlay servlets / delegate to other servlets at runtime [0], similar to what’s already available for scripts. Besides the overlaying functionality, this will allow bundled scripts (optionally precompiled) to be able to delegate rendering to pre-existing servlets / scripts that are not necessarily registered through the new Apache Sling Scripting Bundle Tracker [1].
> 
> Please let me know what you think.
> 
> Regards,
> Radu
> 
> [0] - https://issues.apache.org/jira/browse/SLING-8170 <https://issues.apache.org/jira/browse/SLING-8170>
> [1] - https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker <https://github.com/apache/sling-org-apache-sling-scripting-bundle-tracker>
>