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]
