Hi Carsten, Thanks for doing that and that does solve the problem I had. You got your changes committed before me.
I had similar local changes that also included resolving some sonar warnings and some additional code coverage that I have now proposed as PR #65 <https://github.com/apache/sling-org-apache-sling-api/pull/65>. Regards, Eric On Sat, Jul 12, 2025 at 6:24 AM Carsten Ziegeler <cziege...@apache.org> wrote: > Hi Eric, > > I implemented https://issues.apache.org/jira/browse/SLING-12857 which > should solve your problem. > > If you think that this is ok, I can release the new API. > > Regards > Carsten > > On 11.07.2025 08:48, Carsten Ziegeler wrote: > > Thinking about this for a little bit longer :) > > Maybe the better way is actually to handle it in the wrappers. This > > would be a single place to fix all of these. > > > > Regards > > Carsten > > > > On 11.07.2025 08:17, Carsten Ziegeler wrote: > >> 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 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 > >>>> > >>>> > >>> > >> > > > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org > >
