I created two issues and linked them to SLING-10000.
The encoding stuff is tricky; I remember that this was written to
support non UTF-8 characters. However, I do not know if the charset
parameter is still used. Therefore changing this part has a high
potential to break things, even if the new code looks "correct".
I am not sure if ServletContext#setRequestCharacterEncoding helps us as
this is a global switch - not per request. It also comes with the
problem that we do not have a servlet 4 implementation. This would
require Jetty 10 :( We only have 9, 11 and 12.
Regards
Carsten
On 20.11.2024 19:29, Konrad Windszus wrote:
To simplify RequestParameter handling with encoding I think it is mandatory to
depend on at least servlet API 4.0 to leverage
ServletContext.setRequestCharacterEncoding(String)
(https://jakarta.ee/specifications/servlet/4.0/apidocs/javax/servlet/servletcontext#setRequestCharacterEncoding-java.lang.String-),
see also Servlet Spec 4.0, chapter 3.12
(https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf)
Otherwise it will be hard to support stuff like the _charset_ parameter as
defined in
https://sling.apache.org/documentation/the-sling-engine/request-parameters.html#character-encoding.
I don’t think this is an issue these days though….
Konrad
On 20. Nov 2024, at 17:24, Konrad Windszus <[email protected]> wrote:
Hi Carsten,
Sounds good to clean up before doing the upgrade. Let us track the effort in 2
separate JIRA issues for Multipart-POST and parameter handling. Then we can
collect some entry points to code in them to give a better overview on the
actual effort.
@Carsten: Can you create those ticket and link them to
https://issues.apache.org/jira/browse/SLING-10000?
Thanks,
Konrad
On 20. Nov 2024, at 07:26, Carsten Ziegeler <[email protected]> wrote:
Trying to bring this old thread to life again :)
It seems that most of us agree on these two things: we should some support
Jakarta Servlet for Sling and whatever we do, it should allow to continue to
run existing code without changes.
However, before we get there, we should make us of Servlet 3 as this will most
likely make the Jakarata support much easier.
As Sling was built on top of Servlet 2, it started to use commons-fileupload
for handling multipart post requests. We should replace this with using the
Servlet 3 parts API. This should be straight forward.
In addition, we have a lot of legacy handling for request parameters especially
around encoding in Sling Engine - this is pretty complicated code which in
theory shouldn't be necessary anymore and we could 100% rely on the servlet
engine.
It would be great if there is someone volunteering to look into these. I see at
least the first one as a prerequisite.
Regards
Carsten
On 09.10.2023 15:37, Robert Munteanu wrote:
Hi,
+1 from me on moving to Jakarta Servlet, for the reasons you outlined.
On Tue, 2023-10-03 at 14:08 +0200, Carsten Ziegeler wrote:
Now I totally agree that this must come with nearly zero changes
required for our users. That's why I only suggested solutions where
this
should be true.
On a related topic, there are source-level solutions for migrating to
jakarta.servlet, e.g. [1].
These would be complementary to the eclipse transformer, which looks
like a nice fit as it has both bnd and maven plugins.
Thanks,
Robert
[1]:
https://docs.openrewrite.org/recipes/java/migrate/jakarta/javaxservlettojakartaservlet
--
Carsten Ziegeler
Adobe
[email protected]
--
Carsten Ziegeler
Adobe
[email protected]
