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
