Migrate from javax.* (Java EE) to jakarta.* (Jakarta EE 9+) to enable Spring 6 / modern stack

Summary

Migrate the entire codebase from the legacy Java EE javax.* namespace to Jakarta EE 9+ jakarta.*, and raise the runtime/build baseline accordingly. This is a prerequisite for upgrading Spring Framework to 6.x (and keeping all the transitive deps that have moved to Jakarta).

Motivation

Dependabot PR #770 (bump spring-test 5.3 → 6.0.12) cannot be merged. Spring Framework 6.0 hard-requires Jakarta EE 9+ and Java 17+; its MockHttpServletRequest / MockServletConfig now implement jakarta.servlet.* interfaces, so they no longer satisfy our javax.servlet.* code and compilation fails with ~50 errors across the IT/test sources, e.g.:

incompatible types: org.springframework.mock.web.MockServletConfig
  cannot be converted to javax.servlet.ServletConfig
incompatible types: org.springframework.mock.web.MockHttpServletRequest
  cannot be converted to javax.servlet.http.HttpServletRequest

We are currently pinned to Spring 5.3.31, which is past end of OSS support. There is no path to a modern Spring/servlet stack without the Jakarta migration — it's the only option.

Scope

Current state in the repo:

• 168 Java files import javax.servlet (814 import statements total).
• Other javax.* in play: javax.xml (6), javax.crypto (5, stays javax — JCA is not part of Jakarta), javax.mail (2, → jakarta.mail).
• 122 JSP files + src/main/webapp/WEB-INF/web.xml (taglib URIs and servlet descriptor move to Jakarta namespaces).
• Packaging is war, deployed on Tomcat (Dockerfile FROM tomcat:${TOMCAT_DOCKER_VERSION}).
• Compiler <release> is already 17 — good, satisfies the Spring 6 / Jakarta baseline.

Work items

• Swap servlet dependency: javax.servlet:javax.servlet-api:4.0.1 → jakarta.servlet:jakarta.servlet-api (6.x, Servlet 6.0).
• Replace jstl:jstl:1.2 with the Jakarta JSTL API + Glassfish impl (jakarta.servlet.jsp.jstl:*).
• javax.mail → jakarta.mail (com.sun.mail:jakarta.mail / org.eclipse.angus).
• Review javax.xml usages (JAXB/javax.xml.bind → jakarta.xml.bind if any; javax.xml.parsers/SAX stay in the JDK).
• Bump Spring spring-web / spring-core / spring-context / spring-test to 6.x (then let Dependabot #770 ride along / close it).
• Update the spring-mock / fongo test mocks if they conflict with Jakarta.
• Bulk rename import javax.servlet* → import jakarta.servlet* across the 168 source files (OpenRewrite recipe org.openrewrite.java.migrate.jakarta.JavaxServletToJakartaServlet is the recommended tool for this).
• Reimplement SAML SSO on a Jakarta-native library (decision: pac4j pac4j-saml 6.x) and rewrite the 5 SAML servlets (ACS, SLS, SSOLogin, Logout, SSOMetadata) — building a SAML2Configuration from onelogin.saml.properties, preserving the Getter.authUserSSO(...) hand-off. In-scope migration blocker, done as its own stacked PR. Earlier plan (java-saml 3.0.0 + java-saml-servlet-jakarta) is dead: verified — java-saml's latest release is 2.9.0 (javax-only Auth); the servletless/jakarta split (PR #395) is stalled; java-saml-core 3.x was never published; the only jakarta artifact (Jumpmind 3.0.0.231010) is a 4 KB, 2-class adapter stub with no Auth/core — unusable.
• Migrate 122 JSPs: update taglib URIs (http://java.sun.com/jsp/jstl/... → jakarta.tags.*) and any scriptlet imports.
• Update web.xml to the Jakarta web-app schema/namespace (Servlet 6.0, jakarta.ee).
• Bump the Tomcat base image to Tomcat 10.1+ (first Jakarta-namespace Tomcat); Tomcat 9 will not run a Jakarta servlet app.
• Run the full unit + integration test suite green.

Notes

• javax.crypto stays as-is — it's part of the JCA in the JDK, not Jakarta EE.
• Recommend driving the namespace + import changes with OpenRewrite (org.openrewrite.recipe:rewrite-migrate-java, recipe org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta) to handle the mechanical bulk and reduce review surface, then hand-fix the JSP/web.xml/Tomcat pieces.

Refs: PR #770 (build failure that surfaced this).

Start by reviewing the dependency configuration, Dockerfile, src/main/webapp/WEB-INF/web.xml, the five named SAML servlets, and the JSP files. Run the unit and integration suites to establish the current failures, then track the namespace, dependency, SAML, and Tomcat migration work. Done means the Jakarta-based build and deployment work with all tests passing.