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] >> >
