JBoss Web Server 7 makes Java 17 and deployment topology the real migration work

Red Hat’s migration guidance for the generally available JBoss Web Server 7 argues that Jakarta EE 11 is not the hardest part of the upgrade. The larger risks sit in the Java baseline, changed Tomcat behavior and the deployment assumptions removed with the Java SecurityManager.

What changed

JBoss Web Server 7 is based on Apache Tomcat 11.0.21 and moves to Jakarta EE 11 APIs including Servlet 6.1, JSP 4.0, Expression Language 6.0 and WebSocket 2.2. Red Hat notes that applications already migrated from javax. to jakarta. for JWS 6 do not face another package rename. EL 6.0 instead adds native record support, while its Optional resolver remains disabled by default to avoid changing existing page output.

The behavioral changes deserve closer testing. Tomcat now throws on malformed or oversized parameter bodies rather than returning null; the old FailedRequestFilter has consequently been removed. At the same time, maxParameterCount drops from 10,000 to 1,000. Large forms can therefore cross a lower limit and encounter a different failure path. HTTP/2 server push is gone, and quoted cookie values retain their quotes under the newer RFC behavior.

Who needs to plan

Java 17 is now the minimum runtime, with Java 11 no longer supported. Teams moving from Java 11 should treat the JDK upgrade as a separate project: reflective access to JDK internals can now fail, and older bytecode-manipulation libraries underneath frameworks, test tools and monitoring agents may reject Java 17 class files only when a particular path loads.

The largest architectural change affects deployments that used the Java SecurityManager and catalina.policy to separate applications inside one JVM. Tomcat 11 and JWS 7 remove that mechanism. Red Hat recommends container or virtual-machine isolation instead, which can turn one multi-application instance into several independently operated instances.

OpenShift image users also have a base-image boundary to cross. JWS 7 images are UBI 9 only, and the Prometheus binary previously inherited from the base image is no longer present. Metrics endpoints remain available, but monitoring must come from OpenShift’s stack or a separately deployed Prometheus.

What to do before upgrading

Start by running the application, its instrumentation agents and integration tests on Java 17 before changing JWS. Search startup scripts for java.security.manager, inspect whether catalina.policy still enforces a real boundary, and identify any topology change required to replace it.

Then audit connectors and applications for large parameter sets, remove FailedRequestFilter, guard any newPushBuilder() calls and test cookie handling. Finally, update pipelines that build from UBI 8 and verify image scanning and build hosts against UBI 9. Red Hat also cautions that deploying Spring Boot 4 on JWS 7 is technically possible but outside official support, making ongoing compatibility testing the application team’s responsibility.