Thanks everyone who participated.
We have +1 votes from Robert Munteanu, Konrad Windszus, Jörg Hoh, Radu
Cotescu, Stefan Seifert, Carsten Ziegeler and a +0 vote from Oliver Lietz.
With this result, we have alignment and continue this road.
And I dont want to ignore Oli's additional comment:´"I prefer to have a
Servlet-free core to easier support alternative request/response
implementations and baking."
This was actually our first internal version of Sling before we
contributed it to Apache. While this sounds great, we had learned in the
Apache Cocoon project and in our first attempts with Sling that sooner
or later you and up with an API that is very identical to the servlet
API - and then whenever you want to use other libraries or integrate,
you need wrappers back and forth.
And if we introduce such an API, that would probably require more
changes. With the current approach it is in 95% a simple search/replace.
Regards
Carsten
On 22.01.2025 07:28, Carsten Ziegeler wrote:
Hi,
we need to gather alignment on our approach to Jakarta Servlet. For
discussions on the options please refer to the recent mail threads about
this topic. There are pros and cons for every option, but this proposal
is msot likely the best option for our users.
I think the best way way to gather the alignment is a simple vote. So
here we are.
The proposal is to:
- target at least Jakarta Servlet 6 (depending on timing we might also
go to Jakarta Servlet 6.1)
- due to Jakarta Servlet 6, we increase the minimum required Java
version to Java 17
- duplicate all non deprecated API that uses javax.servlet and create a
variation for jakarta.servlet (see [1] on how this looks for the API)
- our implementation continue to support the javax.servlet based API and
in addition support the jakarta.servlet based API (fully compatible)
Please cast your votes. I'll leave this vote open until the 31st of
January.
Regards
Carsten
[1] https://github.com/apache/sling-org-apache-sling-api/pull/55
--
Carsten Ziegeler
Adobe
cziege...@apache.org
