SLING-13071 - HTL use objects that adapt from the javax SlingHttpServletRequest cannot be instantiated a Jakarta context

[rombert]

Implement a fallback for adapting from the legacy javax servlet requerst when adapting from the jakarta request fails.

Adapters are normally expected to be registered for the legacy javax.servlet-based APIs and we need the adaptions to keep working for backwards compatibility.

[rombert]

This seems to fix the problem but needs more testing.

At a minimum we will need to implement the same fallback for the response object.

[kwin]

Shouldn't this kind of fallback rather be implemented in Sling Models (i.e. register the Model for both servlet request types). Having this for all kind of adaptations feels too magic to me.

[rombert]

I don't think this has to do with models, that is a different problem that also needs to be handled, according to my tests See apache/sling-org-apache-sling-starter-test-services#20 and the IT pull request linked from there for details. And this is very likely unrelated to HTL but that was the scenario where I discovered the problem.

…

On January 24, 2026 2:26:14 PM GMT+01:00, Konrad Windszus ***@***.***> wrote: kwin left a comment (apache/sling-org-apache-sling-engine#68) Shouldn't this kind of fallback rather be implemented in Sling Models (i.e. register the Model for both servlet request types). Having this for all kind of adaptations feels too magic to me. -- Reply to this email directly or view it on GitHub: #68 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[rombert]

Shouldn't this kind of fallback rather be implemented in Sling Models (i.e. register the Model for both servlet request types). Having this for all kind of adaptations feels too magic to me.

BTW, this is what apache/sling-org-apache-sling-models-impl#77 aims to do and it is not enough:

• we need to handle regular adaptables, not only only Sling Models
• when running in a Jakarta environment, the SlingHttpServletRequest.adaptTo call delegates to the actual impl from the Sling Engine, which is a Jakarta impl, therefore only considering adapter factories that adapt from the SlingJakartaHttpServletRequest, leading to this problem.

One possible alternative would be to add a ServiceListener which registers adapter factories for all adapters from SlingHttpServlet(Request|Response) to match their Jakarta counterparts. I haven't tested it that works but for me it has the same degree of 'magic' and the code would be more complicated. I took this kind of approach in apache/sling-org-apache-sling-servlets-post#33, but only because the existing infrastructure already existed; I don't think we should go that way unless we have strong reasons.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud