sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radu Cotescu <>
Subject Re: [servlets] SLING-8170 - Allow Sling servlets to declare a resource super type
Date Wed, 12 Dec 2018 11:43:20 GMT
Hi Konrad,

> On 11 Dec 2018, at 19:11, Konrad Windszus <> 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

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
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.


[2] -
[3] - <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message