Hi Konrad, > On 11 Dec 2018, at 19:11, Konrad Windszus <[email protected]> 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>
