You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2023/10/01 13:59:39 UTC
[RT] Path to Jakarta Servlet Specification
Hi,
we should discuss whether and if how we want to move to the Jakarta
Servlet Specification.
For everyone this is a "quick" recap of todays landscape (in general):
- Sling is based on Servlet 2/3 which uses the javax.servlet package
namespace
- Servlet 4 is the last specification using the javax.servlet namespace
- With the move of all enterprise specifications to the Eclipse, all
specification went through package renaming. Servlet 5 is the first
version using the jakarta.servlet package namespace. It is identical to
Servlet 4 - except for the packages.
- In general, migration from Servlet 4 to Servlet 5 "just" requires all
packages to be renamed; this can be done in source or binaries - at
build time or at runtime.
- The latest specification is Servlet 6 which added minor features to
Servlet 5 *but* removed all things that were deprecated in Servlet 5.
This means if you have code using those deprecated methods, you need to
adjust your code to get to Servlet 6
- It seems that servlet engines like Jetty (which we use through Apache
Felix) require users to migrate. Jetty 9/10 support javax.servlet 3/4,
Jetty 11 only supports Jakarta Servlet 5 and Jetty 12 only support
Jakarta Servlet 6.
- OSGi Specifications: The old http service is tied to javax.servlet.
This one should not be used as it got replaced by the http whiteboard.
- OSGi Specifications: http whiteboard supports Servlet 3/4
- OSGi Specifications: servlet whiteboard supports Servlet 5 (and in
theory Servlet 6).
- OSGi Specifications: It is possible to run all of the above three
specifications in parallel
- Implementation: Apache Felix Http Jetty 5.x supports all of the above
OSGi specifications and Servlet API 2 to 5. You can mix and match old
code with new code - this allows for an easier upgrade path for consumer
as you can transitions parts of your code base one after the other.
When we are talking about Sling, things get more complicated as most of
our API uses javax.servlet as part of the API, so simply changing that
API from javax.servlet to jakarta.servlet will break everyone out there.
Basically all of our API is affected, unfortunately including all the
resource resolver related API packages!.
The Apache Felix Webconsole was in a similar situation as Sling but with
a way smaller API. Here we just created a new API next to the old one,
now allowing to run plugins using old and new API in parallel. This
support works in every servlet engine using javax.servlet - and
eventually will move to require a jakarta.servlet based engine.
So the first question for us is now, do we want to support the Jakarta
Servlet API?
It seems the Java world around us is moving to Jakarta and if we want to
benefit from upcoming new features in that world, we eventually have to
move.
There are different options to do this move:
Option 1: provide new API interfaces based on Jakarta - parallel to the
old ones with side-by-side packages (similar to the web console). Maybe
this should focus on Servlet 6 (with removed deprecated stuff), to not
have two migration steps for the users. While this is also an
opportunity to clean up our API around the Servlet API, it unfortunately
includes a complete fork of our API - and the implementation to support
old and new one will be pretty complex.
Option 2: Update the existing API directly to Servlet 5/6. This breaks
all code out there and forces it to migrate. This is only an option if
we could provide tooling (byte code rewriting?) that either at assembly
or runtime rewrites usage of the old packages to the new packages. This
approach would not allow us to clean up the API. That would need to be
handled separately.
Option 3: do nothing now and wait until this switch is actually becoming
a real problem.
Giving the complexity of this problem, option 3 is maybe not the best
choice. Option 1 is very tempting, but I fear the complexity and risk
involved. I did this work for the web console and it was already quite
challenging there. If Option 2 would work, this could be a nice way out.
Thoughts? Maybe there are better options?
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <kw...@apache.org> 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 <cz...@apache.org> 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
>>> cziegeler@apache.org
>>>
>>
>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Konrad Windszus <kw...@apache.org>.
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 <kw...@apache.org> 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 <cz...@apache.org> 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
>> cziegeler@apache.org
>>
>
Re: [RT] Path to Jakarta Servlet Specification
Posted by Konrad Windszus <kw...@apache.org>.
I just found https://issues.apache.org/jira/browse/SLING-3403, however this still adds a compatibility layer to support Sling on Servlet 2.x. Removing this should be fairly straightforward looking at https://github.com/apache/sling-org-apache-sling-engine/commit/8e5d434d1314141dc2a61f62d7595d3e85dc4da1. However there may be minor differences in handling compared to the one in Sling. The question is to which degree we should test with other servlet engines apart from Jetty?
Konrad
> On 20. Nov 2024, at 17:24, Konrad Windszus <kw...@apache.org> 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 <cz...@apache.org> 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
>> cziegeler@apache.org
>>
>
Re: [RT] Path to Jakarta Servlet Specification
Posted by Konrad Windszus <kw...@apache.org>.
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 <cz...@apache.org> 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
> cziegeler@apache.org
>
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Konrad,
On 02.01.2025 11:54, Konrad Windszus wrote:
> From a consumer perspective I am very much against same name class names in different packages. Leads to lot of issues with IDEs (auto-import) and wrongly imported packages (particularly with non-recommended star imports).
very good point, yes we should avoid duplicate class names (this is one
of the reasons why we prefixed some interfaces with "Sling" like
HttpServletRequest).
> I am in favour of a (stable) Jakarta infix in the name like SlingJakartaHttpServletRequest. I think those are sufficiently stable/accurate for the foreseeable future. Having them in a dedicated package makes sense though for the version range imports.
Agree, that using "Jakarta" should be stable, and if not we can create
new versions with the new name :)
I changed this now for all the relevant interfaces and classes but kept
them in the same packages. In some cases these reference unchanged
interfaces/classes which would then be in a different package.
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Konrad Windszus <kw...@apache.org>.
HI Carsten,
Thanks for the details in the branch.
> On 2. Jan 2025, at 11:27, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> I committed my first attempts into a new branch and added my notes
> https://github.com/apache/sling-org-apache-sling-api/blob/jakarta-2/JAKARTA.md
> In most cases, we just need to add some additional methods. And then there are some interfaces where we need to duplicate.
>
> I think the biggest challenge is finding good names for the new interfaces. I think we should avoid something like V2 or Jakarta in the names. For example I created new packages for some of the interfaces instead. There are some left where I am not sure about a good name yet.
From a consumer perspective I am very much against same name class names in different packages. Leads to lot of issues with IDEs (auto-import) and wrongly imported packages (particularly with non-recommended star imports).
I am in favour of a (stable) Jakarta infix in the name like SlingJakartaHttpServletRequest. I think those are sufficiently stable/accurate for the foreseeable future. Having them in a dedicated package makes sense though for the version range imports.
WDYT?
>
> Happy new year!
> Regards
> Carsten
>
> On 02.01.2025 09:43, Konrad Windszus wrote:
>> Hi Carsten,
>> Do you have some ballpark numbers of how many classes/interfaces are affected?
>> Any ideas yet for a naming scheme for those new Jakarta based interfaces?
>> SlingHttpServletRequestV2 or anything more verbose?
>> Thanks and happy new year 2025
>> Konrad
>>> On 31. Dec 2024, at 11:49, Carsten Ziegeler <cz...@apache.org> wrote:
>>>
>>> I spent some time on this topic and I am now leaning towards solving it differently.
>>>
>>> Our most important requirement is that existing code runs without changes. I think our second most important requirement is to keep maintenance of Sling code manageable as well as not causing too much discomfort to our user base.
>>>
>>> The current plan was to update the most important parts of Sling (API, Engine, Auth) and replace in those bundles javax.servlet with jakarta.servlet. With that Sling would use jakarta servlet and without any further work this would be breaking all existing code. We came up with the idea to have some tooling that rewrites existing bundles and replaces usage of javax.servlet with jakarta.servlet (most likely at deployment or runtime time). With that our main requirement should be solved.
>>>
>>> However, this most likely means that we have to maintain two branches for all those modules for bug fixes. It also means that we create an incompatible change for packages where it does not really make sense. The most prominent one is the resource package where javax.servlet is only used in single methods.
>>>
>>> It also means it is an all or nothing approach for our users. Within a single bundle it is only possible to either use the old API or the new one - as we use the same package and class names. I have the feeling that this will create issues. While replacing in source code is easy, what about testing code, 3rd party libraries etc. All of that out of a sudden needs to work with jakarta.servlet. We have a huge ecosystem and I am almost certain that this will create pain here and there. Might again be solvable to some degree with additional tooling.
>>>
>>> The easier solution for us and our users is most likely that we provide an API that can deal with both servlet APIs, basically duplicating interfaces where required. This allows for a step by step updating of existing user code and provides a much better support in your IDE (the deprecated and the new method are visible).
>>>
>>> I was initially against this as I thought the implementation (in Sling Engine and scripting) will be way too complicated but weighting this pain in the implementation against potential pain for our users, I think we have to take the pain and deal with it. It might not be as bad as I initially thought. And to be fair, the tooling we would need is not there today either - there are some promising basic tools we could built upon, but still it does not come for free.
>>>
>>> Long story short, I heavily favor now Option 1, providing new API based on jakarta.servlet next to the existing one.
>>>
>>> Regards
>>> Carsten
>>>
>>> On 01.10.2023 15:59, Carsten Ziegeler wrote:
>>>> There are different options to do this move:
>>>>
>>>> Option 1: provide new API interfaces based on Jakarta - parallel to the old ones with side-by-side packages (similar to the web console). Maybe this should focus on Servlet 6 (with removed deprecated stuff), to not have two migration steps for the users. While this is also an opportunity to clean up our API around the Servlet API, it unfortunately includes a complete fork of our API - and the implementation to support old and new one will be pretty complex.
>>>>
>>>> Option 2: Update the existing API directly to Servlet 5/6. This breaks all code out there and forces it to migrate. This is only an option if we could provide tooling (byte code rewriting?) that either at assembly or runtime rewrites usage of the old packages to the new packages. This approach would not allow us to clean up the API. That would need to be handled separately.
>>>>
>>>> Option 3: do nothing now and wait until this switch is actually becoming a real problem.
>>>>
>>>> Giving the complexity of this problem, option 3 is maybe not the best choice. Option 1 is very tempting, but I fear the complexity and risk involved. I did this work for the web console and it was already quite challenging there. If Option 2 would work, this could be a nice way out.
>>>>
>>>> Thoughts? Maybe there are better options?
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe
>>> cziegeler@apache.org
>>>
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
I committed my first attempts into a new branch and added my notes
https://github.com/apache/sling-org-apache-sling-api/blob/jakarta-2/JAKARTA.md
In most cases, we just need to add some additional methods. And then
there are some interfaces where we need to duplicate.
I think the biggest challenge is finding good names for the new
interfaces. I think we should avoid something like V2 or Jakarta in the
names. For example I created new packages for some of the interfaces
instead. There are some left where I am not sure about a good name yet.
Happy new year!
Regards
Carsten
On 02.01.2025 09:43, Konrad Windszus wrote:
> Hi Carsten,
> Do you have some ballpark numbers of how many classes/interfaces are affected?
> Any ideas yet for a naming scheme for those new Jakarta based interfaces?
> SlingHttpServletRequestV2 or anything more verbose?
>
> Thanks and happy new year 2025
> Konrad
>
>> On 31. Dec 2024, at 11:49, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> I spent some time on this topic and I am now leaning towards solving it differently.
>>
>> Our most important requirement is that existing code runs without changes. I think our second most important requirement is to keep maintenance of Sling code manageable as well as not causing too much discomfort to our user base.
>>
>> The current plan was to update the most important parts of Sling (API, Engine, Auth) and replace in those bundles javax.servlet with jakarta.servlet. With that Sling would use jakarta servlet and without any further work this would be breaking all existing code. We came up with the idea to have some tooling that rewrites existing bundles and replaces usage of javax.servlet with jakarta.servlet (most likely at deployment or runtime time). With that our main requirement should be solved.
>>
>> However, this most likely means that we have to maintain two branches for all those modules for bug fixes. It also means that we create an incompatible change for packages where it does not really make sense. The most prominent one is the resource package where javax.servlet is only used in single methods.
>>
>> It also means it is an all or nothing approach for our users. Within a single bundle it is only possible to either use the old API or the new one - as we use the same package and class names. I have the feeling that this will create issues. While replacing in source code is easy, what about testing code, 3rd party libraries etc. All of that out of a sudden needs to work with jakarta.servlet. We have a huge ecosystem and I am almost certain that this will create pain here and there. Might again be solvable to some degree with additional tooling.
>>
>> The easier solution for us and our users is most likely that we provide an API that can deal with both servlet APIs, basically duplicating interfaces where required. This allows for a step by step updating of existing user code and provides a much better support in your IDE (the deprecated and the new method are visible).
>>
>> I was initially against this as I thought the implementation (in Sling Engine and scripting) will be way too complicated but weighting this pain in the implementation against potential pain for our users, I think we have to take the pain and deal with it. It might not be as bad as I initially thought. And to be fair, the tooling we would need is not there today either - there are some promising basic tools we could built upon, but still it does not come for free.
>>
>> Long story short, I heavily favor now Option 1, providing new API based on jakarta.servlet next to the existing one.
>>
>> Regards
>> Carsten
>>
>> On 01.10.2023 15:59, Carsten Ziegeler wrote:
>>> There are different options to do this move:
>>>
>>> Option 1: provide new API interfaces based on Jakarta - parallel to the old ones with side-by-side packages (similar to the web console). Maybe this should focus on Servlet 6 (with removed deprecated stuff), to not have two migration steps for the users. While this is also an opportunity to clean up our API around the Servlet API, it unfortunately includes a complete fork of our API - and the implementation to support old and new one will be pretty complex.
>>>
>>> Option 2: Update the existing API directly to Servlet 5/6. This breaks all code out there and forces it to migrate. This is only an option if we could provide tooling (byte code rewriting?) that either at assembly or runtime rewrites usage of the old packages to the new packages. This approach would not allow us to clean up the API. That would need to be handled separately.
>>>
>>> Option 3: do nothing now and wait until this switch is actually becoming a real problem.
>>>
>>> Giving the complexity of this problem, option 3 is maybe not the best choice. Option 1 is very tempting, but I fear the complexity and risk involved. I did this work for the web console and it was already quite challenging there. If Option 2 would work, this could be a nice way out.
>>>
>>> Thoughts? Maybe there are better options?
>>
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Konrad Windszus <kw...@apache.org>.
Hi Carsten,
Do you have some ballpark numbers of how many classes/interfaces are affected?
Any ideas yet for a naming scheme for those new Jakarta based interfaces?
SlingHttpServletRequestV2 or anything more verbose?
Thanks and happy new year 2025
Konrad
> On 31. Dec 2024, at 11:49, Carsten Ziegeler <cz...@apache.org> wrote:
>
> I spent some time on this topic and I am now leaning towards solving it differently.
>
> Our most important requirement is that existing code runs without changes. I think our second most important requirement is to keep maintenance of Sling code manageable as well as not causing too much discomfort to our user base.
>
> The current plan was to update the most important parts of Sling (API, Engine, Auth) and replace in those bundles javax.servlet with jakarta.servlet. With that Sling would use jakarta servlet and without any further work this would be breaking all existing code. We came up with the idea to have some tooling that rewrites existing bundles and replaces usage of javax.servlet with jakarta.servlet (most likely at deployment or runtime time). With that our main requirement should be solved.
>
> However, this most likely means that we have to maintain two branches for all those modules for bug fixes. It also means that we create an incompatible change for packages where it does not really make sense. The most prominent one is the resource package where javax.servlet is only used in single methods.
>
> It also means it is an all or nothing approach for our users. Within a single bundle it is only possible to either use the old API or the new one - as we use the same package and class names. I have the feeling that this will create issues. While replacing in source code is easy, what about testing code, 3rd party libraries etc. All of that out of a sudden needs to work with jakarta.servlet. We have a huge ecosystem and I am almost certain that this will create pain here and there. Might again be solvable to some degree with additional tooling.
>
> The easier solution for us and our users is most likely that we provide an API that can deal with both servlet APIs, basically duplicating interfaces where required. This allows for a step by step updating of existing user code and provides a much better support in your IDE (the deprecated and the new method are visible).
>
> I was initially against this as I thought the implementation (in Sling Engine and scripting) will be way too complicated but weighting this pain in the implementation against potential pain for our users, I think we have to take the pain and deal with it. It might not be as bad as I initially thought. And to be fair, the tooling we would need is not there today either - there are some promising basic tools we could built upon, but still it does not come for free.
>
> Long story short, I heavily favor now Option 1, providing new API based on jakarta.servlet next to the existing one.
>
> Regards
> Carsten
>
> On 01.10.2023 15:59, Carsten Ziegeler wrote:
> > There are different options to do this move:
> >
> > Option 1: provide new API interfaces based on Jakarta - parallel to the old ones with side-by-side packages (similar to the web console). Maybe this should focus on Servlet 6 (with removed deprecated stuff), to not have two migration steps for the users. While this is also an opportunity to clean up our API around the Servlet API, it unfortunately includes a complete fork of our API - and the implementation to support old and new one will be pretty complex.
> >
> > Option 2: Update the existing API directly to Servlet 5/6. This breaks all code out there and forces it to migrate. This is only an option if we could provide tooling (byte code rewriting?) that either at assembly or runtime rewrites usage of the old packages to the new packages. This approach would not allow us to clean up the API. That would need to be handled separately.
> >
> > Option 3: do nothing now and wait until this switch is actually becoming a real problem.
> >
> > Giving the complexity of this problem, option 3 is maybe not the best choice. Option 1 is very tempting, but I fear the complexity and risk involved. I did this work for the web console and it was already quite challenging there. If Option 2 would work, this could be a nice way out.
> >
> > Thoughts? Maybe there are better options?
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
I spent some time on this topic and I am now leaning towards solving it
differently.
Our most important requirement is that existing code runs without
changes. I think our second most important requirement is to keep
maintenance of Sling code manageable as well as not causing too much
discomfort to our user base.
The current plan was to update the most important parts of Sling (API,
Engine, Auth) and replace in those bundles javax.servlet with
jakarta.servlet. With that Sling would use jakarta servlet and without
any further work this would be breaking all existing code. We came up
with the idea to have some tooling that rewrites existing bundles and
replaces usage of javax.servlet with jakarta.servlet (most likely at
deployment or runtime time). With that our main requirement should be
solved.
However, this most likely means that we have to maintain two branches
for all those modules for bug fixes. It also means that we create an
incompatible change for packages where it does not really make sense.
The most prominent one is the resource package where javax.servlet is
only used in single methods.
It also means it is an all or nothing approach for our users. Within a
single bundle it is only possible to either use the old API or the new
one - as we use the same package and class names. I have the feeling
that this will create issues. While replacing in source code is easy,
what about testing code, 3rd party libraries etc. All of that out of a
sudden needs to work with jakarta.servlet. We have a huge ecosystem and
I am almost certain that this will create pain here and there. Might
again be solvable to some degree with additional tooling.
The easier solution for us and our users is most likely that we provide
an API that can deal with both servlet APIs, basically duplicating
interfaces where required. This allows for a step by step updating of
existing user code and provides a much better support in your IDE (the
deprecated and the new method are visible).
I was initially against this as I thought the implementation (in Sling
Engine and scripting) will be way too complicated but weighting this
pain in the implementation against potential pain for our users, I think
we have to take the pain and deal with it. It might not be as bad as I
initially thought. And to be fair, the tooling we would need is not
there today either - there are some promising basic tools we could built
upon, but still it does not come for free.
Long story short, I heavily favor now Option 1, providing new API based
on jakarta.servlet next to the existing one.
Regards
Carsten
On 01.10.2023 15:59, Carsten Ziegeler wrote:
> There are different options to do this move:
>
> Option 1: provide new API interfaces based on Jakarta - parallel to
the old ones with side-by-side packages (similar to the web console).
Maybe this should focus on Servlet 6 (with removed deprecated stuff), to
not have two migration steps for the users. While this is also an
opportunity to clean up our API around the Servlet API, it unfortunately
includes a complete fork of our API - and the implementation to support
old and new one will be pretty complex.
>
> Option 2: Update the existing API directly to Servlet 5/6. This
breaks all code out there and forces it to migrate. This is only an
option if we could provide tooling (byte code rewriting?) that either at
assembly or runtime rewrites usage of the old packages to the new
packages. This approach would not allow us to clean up the API. That
would need to be handled separately.
>
> Option 3: do nothing now and wait until this switch is actually
becoming a real problem.
>
> Giving the complexity of this problem, option 3 is maybe not the best
choice. Option 1 is very tempting, but I fear the complexity and risk
involved. I did this work for the web console and it was already quite
challenging there. If Option 2 would work, this could be a nice way out.
>
> Thoughts? Maybe there are better options?
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Robert Munteanu <ro...@apache.org>.
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
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
Sling is based on servlet 2 - we are not even nicely fitting into the
servlet 3 world. The java world is moving to servlet 5 and 6. Major open
source frameworks have already switched to the jakarta namespace. So if
we don't move, we make it very hard to integrate with the latest and
greatest from other places. Similar, servlet engines supporting
javax.servlet are either already or plan to go into maintenance.
And the other argument is perception. The more we use from the past, the
less we fit into the latest and greatest and the more outdated we are
perceived.
Regards
Carsten
On 02.10.2023 14:27, Bertrand Delacretaz wrote:
> Hi,
>
> On Sun, Oct 1, 2023 at 3:59 PM Carsten Ziegeler <cz...@apache.org> wrote:
>> ..It seems the Java world around us is moving to Jakarta and if we want to
>> benefit from upcoming new features in that world, we eventually have to
>> move...
>
> The move looks like a lot of work, so I think we should be able to
> list actual benefits before deciding to do it.
>
> Especially if there's a cost to users of the Sling APIs - the overall
> cost can be huge.
>
> Do people know what exactly we might miss by not moving?
>
> Are there areas where the current servlet APIs prevent Sling's progress ?
>
>> ...Option 3: do nothing now and wait until this switch is actually becoming
>> a real problem...
>
> That would be my preferred option right now, but answers to my above
> questions might change that.
>
> -Bertrand
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: [RT] Path to Jakarta Servlet Specification
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sun, Oct 1, 2023 at 3:59 PM Carsten Ziegeler <cz...@apache.org> wrote:
> ..It seems the Java world around us is moving to Jakarta and if we want to
> benefit from upcoming new features in that world, we eventually have to
> move...
The move looks like a lot of work, so I think we should be able to
list actual benefits before deciding to do it.
Especially if there's a cost to users of the Sling APIs - the overall
cost can be huge.
Do people know what exactly we might miss by not moving?
Are there areas where the current servlet APIs prevent Sling's progress ?
> ...Option 3: do nothing now and wait until this switch is actually becoming
> a real problem...
That would be my preferred option right now, but answers to my above
questions might change that.
-Bertrand
Re: [RT] Path to Jakarta Servlet Specification
Posted by Carsten Ziegeler <cz...@apache.org>.
A project that might help if we try option 2:
https://github.com/eclipse/transformer (initially written for exactly
this use case)
Regards
Carsten
On 01.10.2023 15:59, Carsten Ziegeler wrote:
> Hi,
>
> we should discuss whether and if how we want to move to the Jakarta
> Servlet Specification.
>
> For everyone this is a "quick" recap of todays landscape (in general):
> - Sling is based on Servlet 2/3 which uses the javax.servlet package
> namespace
> - Servlet 4 is the last specification using the javax.servlet namespace
> - With the move of all enterprise specifications to the Eclipse, all
> specification went through package renaming. Servlet 5 is the first
> version using the jakarta.servlet package namespace. It is identical to
> Servlet 4 - except for the packages.
> - In general, migration from Servlet 4 to Servlet 5 "just" requires all
> packages to be renamed; this can be done in source or binaries - at
> build time or at runtime.
> - The latest specification is Servlet 6 which added minor features to
> Servlet 5 *but* removed all things that were deprecated in Servlet 5.
> This means if you have code using those deprecated methods, you need to
> adjust your code to get to Servlet 6
> - It seems that servlet engines like Jetty (which we use through Apache
> Felix) require users to migrate. Jetty 9/10 support javax.servlet 3/4,
> Jetty 11 only supports Jakarta Servlet 5 and Jetty 12 only support
> Jakarta Servlet 6.
> - OSGi Specifications: The old http service is tied to javax.servlet.
> This one should not be used as it got replaced by the http whiteboard.
> - OSGi Specifications: http whiteboard supports Servlet 3/4
> - OSGi Specifications: servlet whiteboard supports Servlet 5 (and in
> theory Servlet 6).
> - OSGi Specifications: It is possible to run all of the above three
> specifications in parallel
> - Implementation: Apache Felix Http Jetty 5.x supports all of the above
> OSGi specifications and Servlet API 2 to 5. You can mix and match old
> code with new code - this allows for an easier upgrade path for consumer
> as you can transitions parts of your code base one after the other.
>
> When we are talking about Sling, things get more complicated as most of
> our API uses javax.servlet as part of the API, so simply changing that
> API from javax.servlet to jakarta.servlet will break everyone out there.
> Basically all of our API is affected, unfortunately including all the
> resource resolver related API packages!.
>
> The Apache Felix Webconsole was in a similar situation as Sling but with
> a way smaller API. Here we just created a new API next to the old one,
> now allowing to run plugins using old and new API in parallel. This
> support works in every servlet engine using javax.servlet - and
> eventually will move to require a jakarta.servlet based engine.
>
> So the first question for us is now, do we want to support the Jakarta
> Servlet API?
>
> It seems the Java world around us is moving to Jakarta and if we want to
> benefit from upcoming new features in that world, we eventually have to
> move.
>
> There are different options to do this move:
>
> Option 1: provide new API interfaces based on Jakarta - parallel to the
> old ones with side-by-side packages (similar to the web console). Maybe
> this should focus on Servlet 6 (with removed deprecated stuff), to not
> have two migration steps for the users. While this is also an
> opportunity to clean up our API around the Servlet API, it unfortunately
> includes a complete fork of our API - and the implementation to support
> old and new one will be pretty complex.
>
> Option 2: Update the existing API directly to Servlet 5/6. This breaks
> all code out there and forces it to migrate. This is only an option if
> we could provide tooling (byte code rewriting?) that either at assembly
> or runtime rewrites usage of the old packages to the new packages. This
> approach would not allow us to clean up the API. That would need to be
> handled separately.
>
> Option 3: do nothing now and wait until this switch is actually becoming
> a real problem.
>
> Giving the complexity of this problem, option 3 is maybe not the best
> choice. Option 1 is very tempting, but I fear the complexity and risk
> involved. I did this work for the web console and it was already quite
> challenging there. If Option 2 would work, this could be a nice way out.
>
> Thoughts? Maybe there are better options?
>
> Regards
> Carsten
--
Carsten Ziegeler
Adobe
cziegeler@apache.org