Hi Eric,I think the wrappers are "ok". It is AuthenticationSupport which should handle null arguments and not wrap them. We might have a few cases of these here and there. Those which are covered by unit tests should work as expected, those which are not - like this one - need to be found and fixed. I think most methods in the API are annotated with requiring a request or response object to be passed. AuthenticationSupport seems to be an exception.
Regards Carsten On 11.07.2025 06:51, Eric Norman wrote:
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 APIinterfaces based on the old servlet API, although they are still fully working.i suppose most of our other Sling modules' APIs have some reference toSlingHttpServletRequest 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, deprecatedall 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 howto create such a dual-faced API in the best-compatible way?(most of the models in the correct voting process that are releasedtogether 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
-- Carsten Ziegeler Adobe cziege...@apache.org
