Move to Jakarta based application servers

[tmortagne]

See xwiki/xwiki-rendering#318 for the rendering side of things.
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+).

Important

This PR might look like a big change already but it's actually very far from a 100% jakarta XWiki. What was done is really just the strict minimum to work in a jakarta application server and there will still be a lot of work after that to fully migrate to jakarta.
See https://design.xwiki.org/xwiki/bin/view/Proposal/Jakartamigration for more details.

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

Migration to jakarta

• 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 have 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, keeping the same class name also reduce the number of changes in the web.xml (in a sense, breaking them improve retro compatibility).
• 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
• Move to XJetty to Jetty 12 EE10 (instead of EE8)
• XWiki is now doing its best by default (in Jetty and Tomcat only right now) to enable everything it can find to allow any character in URLs at init
• New Tomcat 10 based Debian packages

Behavior changes

• Redirect URLs 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)

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.

• it did not made any sense for GenericProvider to be public, so I deprecated it and introduced two new internal tools (one for javax and the other for jakarta) to take care of the default Provider implementation/

TODO

• 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

Not much new tests, but every single UI test and a lot of unit tests are impacted by this change so just the fact that they are passing is a good test. I also tried to migrate as little as possible from javax to jakarta as a way to test the bridges.

Expected merging strategy

• Prefers squash: Yes

[manuelleduc]

I also tried to migrate as little as possible from javax to jakarta as a way to test the bridges.

@tmortagne it this a temporary step to validate the bridge? i.e., do we want to move all javax to jakarta quickly?

[tmortagne]

@tmortagne it this a temporary step to validate the bridge? i.e., do we want to move all javax to jakarta quickly?

The way I see it, the idea would be to migrate existing code only after a few releases, and we are happy with how things are behaving. But new code should obviously try to use jakarta APIs as much as possible (I tried to provide jakarta versions of all the APIs and to deprecate javax based ones, at least for stuff which have been migrated already like servlet and inject).

[michitux]

There seem to be subtle bugs in some of the adapters and converters. It would be great if we could have automated tests that protect against such bugs similar to the tests that I wrote for listeners, see, e.g., https://github.com/xwiki/xwiki-rendering/blob/9ac37383fe66215642ffc9f01e456c294a9f422f/xwiki-rendering-api/src/test/java/org/xwiki/rendering/listener/chaining/AbstractChainingListenerTest.java#L191. There also appear to be quite some TODOs left, do you plan to implement the missing parts or at least document clearly what is unsupported?