Move to Jakarta based application servers

[tmortagne]

See xwiki/xwiki-platform#3388 for the platform side of things.

Jira URLs

• XCOMMONS-2108: Upgrade to Bean Validation 3.0.2
• XCOMMONS-2109: Upgrade to Hibernate Validator 8.0.1
• XCOMMONS-2475: Use Expressly instead of Apache EL
• XCOMMONS-2777: Support both javax.inject and jakarta.inject annotations
• XCOMMONS-2797: Allow accessing a javax.inject.Provider as a jakarta.inject.Provider and the opposite
• XCOMMONS-2962: Provide a javax/jakarta bridge for Servlet APIs
• XCOMMONS-2963: Upgrade to Servlet 5.0
• XCOMMONS-2994: Upgrade to Websocket 2.1.1
• XWIKI-13963: Stop relying on the application server by default to resolve relative redirect URLs
• XWIKI-22586: Check all redirect URLs
• XWIKI-21137: Impossible to install XWiki Debian tomcat packages on Debian 12+ and Ubuntu 24.04+

Changes

Description

The idea is to do just enough for XWiki to work in jakarta based Application servers (Jetty 11+, Tomcat 10+).

Jakarta WebSocket 2.1.1

XWiki has been migrated to WebSocket 2.1.1 without any kind of bridge, so every WebSocket related APIs are broken. There was no obvious way to keep supporting WebSocket 1 but fortunately no use of those APIs were found in contrib extensions.

Jakarta Validation 3.0.2

XWiki has been migrated to Validation 3.0.2 (and Hibernate Validator 8.0.1) without any kind of bridge. A Javax Validation API JAR remain in the XWiki WAR because it's referenced by Jersey, but XWiki itself only support Jakarta Validation. In practice, it just means that Javax Validation annotations used in a contrib extension are going to be ignored. It's easy for an extension to support both Javax and Jakarta XWiki versions by declaring both Java Javax and Jakarta Validation annotations.

Jakarta Servlet 5.0

• A javax.servlet <-> jakarta.servlet has been introduced.
• No Servlet related API should be broken.
• Except that the Filter and Servlet implementations declared in web.xml has all been moved to jakarta without keeping a javax compatible version. The reason is that there is no point keeping supporting those if XWiki is only used in jakarta based application servers.
• Redirect URL are now checked in all contexts (injected by a servlet filter for all requests)
• By default, relative redirect URLs are now resolved by XWiki instead of the application server (reduce setups requirement)
• All the oldcore servlet related APIs are now deprecated
  • The most commons Servlet related API has been added to the Container API to reduce the need to directly access it
  • A new script oriented Container API has been introduced
• New Tomcat 10 based Debian packages

Jakarta Inject 2.0.1

It was probably not strictly required, but both javax and jakarta Inject APIs are now supported at the same time.

Not migrated

It's not strictly required to migrate everything to jakarta.* to work in a jakarta application server like Jetty or Tomcat (we should do it eventually of course, but we can do that in several steps):

See https://design.xwiki.org/xwiki/bin/view/Proposal/Jakartamigration for more details.

TODO

• make Sonar happy with the new rules
• try to hack Jetty EE10 to force it to allow special escaped characters
• quite a few UI tests failing (but need to fix previous point first to reduce the noise since it's causing a lot of those)
• check if it's still possible to allow any special escaped character in Tomcat 10.1 and 11 just with configuration
• run/fix Environment Tests
• would be good to optimize a bit more the size of the xjetty package (i.e. add some more JAR exclusions)

Executed Tests

Expected merging strategy

• Prefers squash: Yes