Nice work Carsten - kudos!
-Rob Walker

-----Original Message-----
From: Carsten Ziegeler <cziege...@apache.org> 
Sent: Thursday, November 30, 2023 6:08 AM
To: dev@felix.apache.org
Subject: Re: The road from Servlet API 3 to Servlet API 6

Update:

I think we have now complete support for servlet 5 and 6 - I haven't done 
extensive testing, so there might be some bugs/problems here and there.

We have now two jetty modules, the http.jetty 5.x running on Java 11, 
supporting servlet 5 and the new http.jetty12 module, running on Java 17 and 
supporting servlet 6.

Both are nearly identical with some minor exceptions due to changes between 
Jetty 11 and 12. But I couldn't find a good way to avoid forking. I don't think 
thats a major issue as we rarely have to touch that code, other than for jetty 
updates anyway.

http.base supports servlet 5 and 6 and therefore can be shared by the two.

Both versions supports all existing OSGi standards in the http world, 
supporting the javax.servlet world as well as the jakarta.servlet world. 
They pass all our integration tests and I expect them to pass the OSGi CTs as 
well, but didn't check.

Regards
Carsten

On 13.09.2023 07:23, Carsten Ziegeler wrote:
> Update:
> 
> The released web console 4.9.4 is based on Servlet API 3 but allows to 
> run plugins using Servlet API 5/6 (that support is optional).
> 
> All web console plugins have been reworked and released to leverage 
> Servlet API 5/6. They work with the above mentioned web console version.
> 
> The upcoming web console 5.0.0 release is based on Servlet API 5, but 
> also runs with 6 and in addition supports plugins written for Servlet 
> API 3 (that support is optional).
> 
> I played a little bit with our http jetty implementation and I think 
> even there we can get away without too much branching for serlvet API 
> 5 vs 6:
> 
> We could release a new servlet api jar that exports all servlet APIs 
> from 2 to 6 (the current version exports 2 to 5). For servlet API 5/6 
> it will use servlet API 6 class files. The only minor problem is if 
> this api is used with client code using the methods/classes that exist 
> in servlet API 5 but where removed with 6. Chances are pretty low and 
> I think thats a good compromise.
> 
> http.base can work with servlet API 5 and 6 as well.
> 
> That leaves us with http.jetty and maybe http.base where we might need 
> branching.
> 
> Regards
> Carsten
> 
> On 24.08.2023 08:06, Carsten Ziegeler wrote:
>> Hi
>>
>> some of our released modules are still based on Servlet API 3. 
>> Starting with version 5 of the Servlet API, the packages have been 
>> renamed from javax.servlet to jakarta.servlet and with version 6 of 
>> the API, deprecated methods have been removed.
>>
>> This means that a module compiled for Servlet API 3 does not run ootb 
>> with Servlet API 5. And a module compiled for Servlet API 5 might not 
>> run ootb with Servlet API 6.
>>
>> For users of our modules we have to provide a way forward to allow 
>> them to leverage newer Servlet API versions - but without loosing our 
>> user base or making it unnecessarily hard for them. We have a large 
>> user base out there which is still on Servlet API 3.
>>
>> This is how I think a path forward can look like:
>>
>> For our http server implementation (http jetty and http bridge), we 
>> have the 4.x branch - it supports Servlet API 3, OSGi HTTP Service 
>> and OSGi HTTP Whiteboard 1.x. We'll continue to provide fixes for 
>> this branch. However this branch is based on Eclipse Jetty 9.4 and 
>> the Jetty project recommends to update to newer Jetty versions.
>>
>> For users who want to leverage Servlet API, we have http jetty and 
>> http bridge 5.x on our main branch. This is based on Jetty 11. Our 
>> implementation on the main branch supports Servlet API 3, Servlet API 
>> 5, OSGi HTTP Service and OSGi HTTP Whiteboard 1.x and 2.x. This 
>> allows our users to run modules using older servlet APIs with modules 
>> using newer Servlet APIs in parallel - without a need to migrate their code.
>> We should encourage our users to move to this version - which should 
>> be a drop-in replacement for most users. Only users who also leverage 
>> Jetty API of 9.x might need to update their code to Jetty API 11.x.
>>
>> Most of the other modules in Apache Felix around servlets are the 
>> webconsole and various webconsole plugins. Currently the webconsole 
>> uses Servlet API 3 and the OSGi HTTP Service. With the next release 
>> of the webconsole, we will move to the OSGi HTTP Whiteboard 1.x away 
>> from the outdated OSGi HTTP Service. In addition the webconsole will 
>> optionally support *plugins* using the Servlet API 5. This gives a 
>> migration path for all plugins while still allowing all of this to 
>> run in a Servlet API 3 container.
>>
>> With that in place, we can migrate our webconsole plugins to Servlet 
>> API 5. And we already started with this in our code base.
>>
>> Once we have all plugins migrated, we can switch the webconsole to be 
>> based on Servlet API 5, OSGi HTTP Whiteboard 2.x and then optionally 
>> support plugins using Servlet API 3. With that all our code should be 
>> on Servlet API 5 - but all existing plugins regardless if they use 
>> Servlet API 3 or 5 should still work in the webconsole.
>>
>> The final piece is Servlet API 6 - I think for the webconsole and the 
>> plugins, we can make them work with Servlet API 5 and Servlet API 6 
>> by basing them on Servlet API 5 and avoiding the removed methods. 
>> This way we don't need to maintain any branches for all of that code.
>>
>> But for the http server implementations (http base and http jetty) 
>> this is not possible. We already have a branch for those leveraging 
>> Jetty 12 which supports Servlet API 6. However, this version does not 
>> support any earlier Servlet API. While it is good to get this work 
>> started, I think the first hill we have to climb is to get all our 
>> code to use Servlet API 5 and take our users with us. Once we are 
>> there we can look down on the road ahead to Servlet API 6 as we will 
>> have a much clearer view by then.
>>
>> Regards
>> Carsten
> 

--
Carsten Ziegeler
Adobe
cziege...@apache.org

Reply via email to