At the point in time when we ship it the Jetty implementation 12.1.x supporting 
Servlet 6.1 should be stable. Currently it is at alpha1 
(https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.0.alpha1)

> On 9. Jan 2025, at 18:45, Konrad Windszus <[email protected]> wrote:
> 
> Happy new year everyone,
> 
> +1 for Servlet 6.1 (which is documented to require Java 17+ in 
> https://jakarta.ee/specifications/servlet/6.1/).
> 
> I would definitely go for deprecating the old javax based classes at the same 
> time we introduce the new ones.
> Hopefully then we don’t run into the situation where we have to come up with 
> bugfixes for the javax based one.
> 
> Konrad
> 
> 
>> On 9. Jan 2025, at 17:25, Robert Munteanu <[email protected]> wrote:
>> 
>> Hi Carsten and Happy New Year!
>> 
>> On Mon, 2025-01-06 at 09:44 +0100, Carsten Ziegeler wrote:
>>> Happy New Year!
>>> 
>>> In the last days I worked a little bit on a prototype to fully
>>> support 
>>> Jakarta Servlet API for Sling. As discussed in the "[RT] Path to
>>> Jakarta 
>>> Servlet Specification" I switched to a different approach which 
>>> basically adds support for Jakarta Servlet next to Javax Servlet by 
>>> adding new methods and interfaces to our API.
>>> 
>>> I have the core now up and running and at least sling-mini (in our 
>>> whiteboard) seems to work. This should cover all functionality except
>>> script support. While you can register servlets and filters based on
>>> the 
>>> Jakarta Servlet API, any script language support is still based on 
>>> Servlet 3.
>>> 
>>> But I think this is good enough to see that this approach is feasible
>>> and we can decide whether we want to go this route.
>> 
>> I took a brief look at the API bundleonly. Having no breaking changes
>> is very encouraging. There is of course some duplication, e.g. between
>> SlingSafeMethodsServlet and SlingJakartaSafeMethodsServlet. Duplication
>> is not the worst thing to happen, but I was wondering if you have any
>> thoughts about making sure the implementations stay consistent. For
>> instance, a generic bugfix should be applicable to both Jakarta and
>> Servlet API variants.
>> 
>>> 
>>> We also need to decide which Jakarta Servlet version we want to
>>> target. 
>>> So far I selected version 6 which is the latest version currently 
>>> implemented by Eclipse Jetty. This brings Sling as much up to date as
>>> possible, but comes with the requirement to run latest Eclipse Jetty
>>> 12 
>>> which requires Java 17. Its probably time to make this switch.
>>> The other option is to go with Jakarta Servlet 5 but that means we
>>> make 
>>> an update to base Sling on older versions. Doesn't feel right.
>> 
>> Java 17 and Servlet 6 sound good to me.
>> 
>> Thanks a lot for picking this up!
>> 
>> Robert
> 
> 

Reply via email to