You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Eric Norman <er...@gmail.com> on 2025/07/11 04:51:28 UTC
Re: Way forward to Sling API 3.0.0/Jakarta Servlet for all other Sling Modules?
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 <cz...@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
> cziegeler@apache.org
>
>
Re: Way forward to Sling API 3.0.0/Jakarta Servlet for all other Sling Modules?
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Eric,
looks good - I always forget that we can now use Java 17 language
features :)
Thanks
Carsten
On 12.07.2025 22:38, Eric Norman wrote:
> 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 <cz...@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 <cziegeler@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
>>>>>> cziegeler@apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>>
>>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Way forward to Sling API 3.0.0/Jakarta Servlet for all other Sling Modules?
Posted by Eric Norman <er...@gmail.com>.
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 <cz...@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 <cziegeler@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
> >>>> cziegeler@apache.org
> >>>>
> >>>>
> >>>
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>
>
Re: Way forward to Sling API 3.0.0/Jakarta Servlet for all other Sling Modules?
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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
>>>> cziegeler@apache.org
>>>>
>>>>
>>>
>>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Way forward to Sling API 3.0.0/Jakarta Servlet for all other Sling Modules?
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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
>>> cziegeler@apache.org
>>>
>>>
>>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Way forward to Sling API 3.0.0/Jakarta Servlet for all other Sling Modules?
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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
>> cziegeler@apache.org
>>
>>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org