Carsten, What is the expectation regarding null request/response handling with the javax<->jakarta servlet conversion wrappers? It doesn't look like the JavaxToJakartaResponseWrapper methods are annotated to indicate if null is allowed for the args and return values or not.
For example, I was trying to migrate my project to the latest releases and I ran into a scenario where it was using the (o.a.sling.auth.core) AuthenticationSupport service in a JettyWebSocketCreator to handle security for a websocket upgrade request. The call to authSupport.handleSecurity(httpRequest, null) used to work but now down the call stack it throws a ClassCastException when the org.apache.sling.api.wrappers.JakartaToJavaxResponseWrapper#toJavaxResponse creates the wrong type of object to wrap the null response arg. The ServletResponseWrapper object it created can't be cast to HttpServletResponseWrapper. I was passing a null response argument because the JettyServerUpgradeResponse in the JettyWebSocketCreator factory doesn't expose the original http response anywhere. I could workaround the problem by providing a mock response object instead of null, or can we try to make a null response argument work as it did before? For your reference, the top of the stack trace looked like this: Caused by: java.lang.ClassCastException: class org.apache.felix.http.javaxwrappers.ServletResponseWrapper cannot be cast to class javax.servlet.http.HttpServletResponse (org.apache.felix.http.javaxwrappers.ServletResponseWrapper is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @64e60e10; javax.servlet.http.HttpServletResponse is in unnamed module of loader org.apache.felix.framework.BundleWiringImpl$BundleClassLoader @7646c397) at org.apache.sling.api.wrappers.JakartaToJavaxResponseWrapper.toJavaxResponse(JakartaToJavaxResponseWrapper.java:56) [org.apache.sling.api:3.0.0] at org.apache.sling.auth.core.impl.AuthenticationHandlerWrapper$HandlerWrapper.extractCredentials(AuthenticationHandlerWrapper.java:64) [org.apache.sling.auth.core:2.0.0] at org.apache.sling.auth.core.impl.AuthenticationHandlerHolder.doExtractCredentials(AuthenticationHandlerHolder.java:91) [org.apache.sling.auth.core:2.0.0] at org.apache.sling.auth.core.impl.AbstractAuthenticationHandlerHolder.extractCredentials(AbstractAuthenticationHandlerHolder.java:57) [org.apache.sling.auth.core:2.0.0] at org.apache.sling.auth.core.impl.SlingAuthenticator.getAuthenticationInfo(SlingAuthenticator.java:756) [org.apache.sling.auth.core:2.0.0] at org.apache.sling.auth.core.impl.SlingAuthenticator.doHandleSecurity(SlingAuthenticator.java:513) [org.apache.sling.auth.core:2.0.0] at org.apache.sling.auth.core.impl.SlingAuthenticator.handleSecurity(SlingAuthenticator.java:483) [org.apache.sling.auth.core:2.0.0] ... Regards, Eric On Thu, Jun 26, 2025 at 9:49 AM Carsten Ziegeler <cziege...@apache.org> wrote: > Some of the modules in the release vote, e.g. engine, servlets post have > such API as well - and for all of those I duplicated the API to be able > to write code using those APIs which does not rely on anything deprecated. > > The implementation (and same is true for the implementation of the API) > directly implements the Jakarta variant. The javax variant is usually > implemented by using wrappers and then invoking the Jakarta variant. > In most cases this is very straight forward, but I agree that its not > the nicest. > > Regards > Carsten > > On 26.06.2025 09:46, Stefan Seifert wrote: > > with the release of Sling API 3.0.0 we have deprecated all API > interfaces based on the old servlet API, although they are still fully > working. > > > > i suppose most of our other Sling modules' APIs have some reference to > SlingHttpServletRequest and similar baked in their own API (i'm thinking > e.g. of Sling Models, Context-Aware configuration). although still working, > they are all now referencing deprecated parts of the API, and should give > users the opportunity to switch to latest Jakarta Servlet API. > > > > does this mean we have to go through all of these modules, deprecated > all APIs which are "tainted" with old Servlet API references and create a > new parallel interface with Jakarta servlet API and release a new major > version of the bundle; same as in the Sling API itself? that seems to be > quite a lot of work, esp. keeping old and new versions of the interfaces > running in parallel. > > > > maybe it would be helpful to create a wiki page with recommendation how > to create such a dual-faced API in the best-compatible way? > > > > (most of the models in the correct voting process that are released > together with the API 3.0.0 do not have their own API, so we don't have > much blueprints except the Sling AIP 3.0.0 itself) > > > > stefan > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org > >
