Upgrading your web server layer can mean an afternoon of dependency updates or 3 months of effort troubleshooting breaking changes. With Red Hat JBoss Web Server (JWS) 7 now generally available—bringing Apache Tomcat 11.0.21, Jakarta EE 11, and Java 17—here is what actually impacts your builds and deployments.
Release announcements tend to lead with the new specs, while the changes that really affect you end up in a section called "Deprecated features." The release notes already list everything, so let's talk instead about what these changes mean for your applications, your builds, and how you deploy.
Apache Tomcat 11 and Jakarta EE 11
JWS 7 is based on Apache Tomcat 11.0.21. That brings in the Jakarta EE 11 specs: Servlet 6.1, Server Pages 4.0, Expression Language (EL) 6.0, WebSocket 2.2, Authentication 3.1, and Annotations 3.0.
Why this matters: This upgrade is smaller than it looks. The painful part of the Jakarta move was renaming every javax.* import to jakarta.*. That happened back in JWS 6.0. You already did it, and nothing gets renamed this time. If you've been putting this off because JWS 5 to 6 was painful, this one is different.
What you get instead is a handful of long-standing gaps finally closed. Expression Language (EL) 6.0 fixes one that has quietly cost teams work. Records have no getters, so EL couldn't read them:
public record Order(String id, BigDecimal total) { }<!-- Unresolved before EL 6.0. Works now. -->
${order.total}The new RecordELResolver handles this, and it's on by default. There's also an OptionalELResolver for unwrapping java.util.Optional. That one ships off by default, because turning it on would change how existing pages render.
Servlet 6.1 adds conveniences in the same vein. The most useful are new sendRedirect overloads that let you pick the status code and keep your response body, instead of always sending a 302 with a container-generated one.
Potential breaking changes
While Jakarta EE 11 closes long-standing gaps, Tomcat 11 introduces behavioral changes worth reviewing before deployment.
Parameter parsing now throws instead of returning null. When a request body is malformed or exceeds a size limit, Tomcat used to swallow the error and hand back null from getParameter(). You couldn't tell a missing field from a failed parse. Servlet 6.1 throws a runtime exception instead. If your code treats a null parameter as its error path, that path changed.
Tomcat 11 removed FailedRequestFilter. It existed only as the workaround for the previous problem—it looked for the request attribute Tomcat set on a parse failure and returned a proper error response. Now that the API throws on its own, the filter is unnecessary and gone. Remove any reference to it from your web.xml, or the application won't start.
maxParameterCount now defaults to 1,000, down from 10,000. On its own, this is a tuning change. Combined with the previous two changes, it's a trap: the threshold that triggers a parse failure is 10 times tighter, and what used to be a silent null is now a thrown exception. A bulk-edit screen or a large multi-select form that worked fine on JWS 6 can start failing. If you have big forms, set this explicitly on the connector instead of inheriting the new default.
HTTP/2 server push is gone. newPushBuilder() now returns null, so an unguarded call is a NullPointerException (NPE). Push has been deprecated across the industry for years—browsers dropped support well before the spec did—and the replacement is a Link: </app.css>; rel=preload response header.
Prometheus is no longer in the base image. Because JWS for OpenShift moved to Universal Base Image 9 (UBI 9), the base image no longer includes the bundled Prometheus binary from Red Hat Enterprise Linux (RHEL). If you've been pulling Prometheus from the base layer to monitor JWS or track performance, it won't be there after the upgrade. This is about where the Prometheus binary comes from, not about what JWS exposes—your metrics endpoints are unaffected. You'll need another source: the built-in monitoring stack if you're on OpenShift, or a separately deployed Prometheus if you're not.
If your application sets cookie values directly, note that Tomcat 11 now retains quotes in quoted cookie values per RFC 6265. A cookie written as foo="bar" gives you "bar", not bar.
Java 17 is the primary upgrade prerequisite
Tomcat 11 requires Java 17 or later, making Java 17 the new baseline for JWS 7. Unlike JWS 6.1, Java 11 is no longer supported on any platform.
Why this matters: If you're still on Java 11, this is 2 migrations, not 1. The Java Virtual Machine (JVM) half is usually the slow one. Two things break most often.
The first is strong encapsulation. Java 16 started blocking reflective access into Java Development Kit (JDK) internals, and Java 17 removed the --illegal-access flag that let you turn the block off. Code that reaches into sun.misc or private JDK fields only logged a warning on Java 11. On Java 17 it throws InaccessibleObjectException. You can still open specific packages with --add-opens, but you have to know which ones, and each one becomes a flag you maintain.
The second risk involves bytecode manipulation. Popular libraries like ASM, Byte Buddy, cglib, and Javassist—which sit under Hibernate, Spring, and Mockito—must understand Java 17's class file format to function. Older versions fail on classes they can't parse. That reaches further than you'd expect, because Hibernate, Spring, Mockito, and most Application Performance Monitoring (APM) agents sit on one of those libraries.
What makes this deceptive is your own code compiles fine either way. The failures land at class-load time, or the first time a particular code path runs. APM agents are usually only enabled in staging and production, so a clean local build tells you very little.
Do the JDK move first, as its own project.
On modern platforms, JWS 7 certifies JDK 25 across Red Hat Enterprise Linux 9 and 10, as well as Windows Server 2019 and 2022. Two things to watch if a platform move is coming: RHEL 8 tops out at Java 21, and RHEL 10 starts there. Java 17 isn't certified on RHEL 10 at all.
What's been removed
The Java SecurityManager is gone. Tomcat 11 removed it, following the JDK's own deprecation for removal, and JWS 7 removes it with them. This is not a deprecation warning you can defer. If you start JWS with -Djava.security.manager and rely on catalina.policy to sandbox untrusted or semi-trusted applications sharing an instance, that mechanism no longer exists.
Red Hat recommends achieving equivalent containment through container isolation—running a single web application per JWS instance in its own container or virtual machine (VM). That's the direction the industry moved for good reasons—the SecurityManager was a porous boundary with a real performance cost, and a container gives you a stronger one. But be clear about what the swap involves. Going from N applications in 1 JVM to N isolated instances changes your deployment topology, your resource footprint, and your operational surface. It's an architecture decision, not a configuration change, and it's the single item in this release most likely to need planning time.
JWS for OpenShift images on UBI 8 are gone. From 7 onward, JWS for OpenShift images are built on UBI 9 only. The upside is the headline: UBI 9 images move from Technology Preview to full support, which is what makes JWS on OpenShift production-supportable under a subscription. If your platform or DevOps team owns base image updates and scanning policies, flag this change to them early so your pipeline is ready before you start code migration.
A note on Spring Boot 4
While deploying Spring Boot 4 to JWS 7 is technically possible thanks to Tomcat 11, note that this configuration falls outside official Red Hat support. If you choose this path, your team will be responsible for ongoing integration testing.
Before you upgrade
Three things to confirm before you schedule the work:
- Are you on Java 17 or later? If not, that's the first project, not a step in this one.
- Do you depend on the
SecurityManager? Search your startup scripts forjava.security.managerand check whethercatalina.policyis doing real work. If it is, you need a topology plan. - Do your images build
FROMUBI 8? Update the base image and verify your scanning and build hosts follow.
For the full list of changes, resolved issues, and the complete operating system/JVM certification matrix, see the Red Hat JBoss Web Server 7 release notes.
