Apache Struts 7.2: What's New, Release History & Support Lifecycle

What Is New in Apache Struts 7.2

What security hardening does Struts 7.2 add?

Struts 7.2 closes several gaps around request parsing and parameter binding, which is where most historical Struts CVEs have originated. In practice, this release continues the parameter allowlisting work started in earlier 6.x and 7.x versions and pushes it deeper into REST and JSON handling.

The most notable additions:

• XML parsers used internally are hardened against entity expansion attacks (the classic "Billion Laughs" pattern), reducing the risk of denial-of-service via crafted XML configuration or payloads.
• The PostbackResult now HTML-encodes the form action attribute, closing an XSS vector in error-rendering scenarios.
• @StrutsParameter is now enforced when deserializing JSON and REST request bodies, not just for standard form parameters.
• Jackson-based REST handlers gained per-property authorization, so individual fields can be rejected even if the containing object is otherwise allowed.
• CookieInterceptor is now gated through ParameterAuthorizer, bringing cookie-based parameters under the same allowlist model as other inputs.
• Redirect URL escaping in non-302 response bodies has been hardened, and TokenHelper no longer logs raw token values.

This matters if your application exposes JSON or REST actions with model-bound properties. Watch out for actions whose setters were never explicitly annotated, since requests that previously populated those fields silently may now be rejected during binding.

Does Struts 7.2 support Jakarta EE 11 and Java 25?

Yes, Struts 7.2 adds compilation support for Jakarta EE 11 and the project build now targets Java 25, on top of the Jakarta EE baseline already established in the 7.x line.

This support is additive rather than a forced migration. Most teams running Struts 7.x on Jakarta EE 10 containers such as Tomcat 10 or 11 do not need to change anything to keep running on 7.2. The practical benefit is that teams planning a move to Jakarta EE 11-capable servers or newer JDKs do not need to wait for a future Struts release to start that work, and can validate compatibility against 7.2 now.

In practice, treat this as an enabling change: confirm your application server and any Jakarta EE-aware libraries (Jackson, Jetty, Weld, and similar) are aligned before assuming a smooth jump to a Jakarta EE 11 runtime.

How does Struts 7.2 improve java.time handling in forms and JSON?

Struts 7.2 extends both the core type conversion layer and the JSON plugin to natively understand LocalDate, LocalTime, and OffsetDateTime, removing the need for many of the custom converters teams previously wrote to bridge java.time with Struts form fields and JSON payloads.

Concretely:

• The built-in DateConverter now works with LocalDate and LocalTime properties on action classes, in addition to the legacy java.util.Date support.
• A new conversion handler covers OffsetDateTime, useful for APIs that need timezone-aware timestamps.
• The JSON plugin gained corresponding java.time support, so REST actions can accept and return these types without bespoke (de)serializers.

This matters if your codebase has accumulated custom TypeConverter implementations or Jackson modules purely to support java.time. Most teams can remove that boilerplate after upgrading, though it is worth keeping the old converters around during testing in case of subtle formatting differences (for example, default ISO-8601 formatting versus a custom pattern your application previously relied on).

What changes to autowiring and parameter authorization need attention before upgrading?

Two changes in Struts 7.2 can alter runtime behavior without any code change on your part, which makes them the highest-priority items for upgrade testing.

First, the autowire alwaysRespect setting now defaults to true. In practice, this affects how Struts resolves Spring-managed beans during autowiring, and applications that relied on the previous default may see different beans injected, or injection failures where none existed before. If your application mixes Spring configuration styles (XML and annotation-based), this is the first place to look if you see unexpected NoSuchBeanDefinitionException or wiring errors after upgrading.

Second, @StrutsParameter enforcement now applies to JSON and REST body deserialization. Any setter that should be populated from a JSON or REST payload needs to be explicitly annotated, for example:

public class UserAction {
    private String email;

    public void setEmail(String email) {
        this.email = email;
    }
}

becomes:

public class UserAction {
    private String email;

    @StrutsParameter
    public void setEmail(String email) {
        this.email = email;
    }
}

Watch out for actions that rely on chained or model-driven objects, since the chaining and chained-property paths are part of the same allowlist tightening in this release. Most teams should run a full regression pass on JSON and REST endpoints after upgrading, paying particular attention to any setter that was relying on implicit allow-by-default behavior.

What other fixes and developer experience improvements landed in Struts 7.2?

Beyond security and Jakarta EE work, 7.2 carries a long list of smaller fixes that mostly affect convention-based projects, interceptor configuration, and template rendering.

• The convention plugin now correctly handles wildcard exclusion patterns for root packages and no longer fails outright when it encounters a NoClassDefFoundError during action class scanning, which previously could break application startup in environments with optional dependencies on the classpath.
• HttpMethodInterceptor and default-action-ref both received fixes for wildcard-based action names, which is relevant if your struts.xml leans heavily on wildcard mappings.
• A classloader and memory leak affecting Tomcat hot deployment has been resolved, which matters for teams that frequently redeploy WAR files without restarting the JVM in staging or development environments.
• The new HTML5 theme gives UI tag users a modern alternative to the long-standing xhtml and simple themes, with its own test suite.
• FreeMarker templates can now use configurable whitespace stripping and a compress tag, useful for reducing rendered page size without hand-trimming templates.
• The JSON plugin now supports configurable request size limits, giving teams a built-in way to cap payload sizes instead of relying solely on container-level settings.

None of these individually require code changes, but the convention plugin and interceptor fixes are worth a quick review if your application has worked around any of these issues with custom code, since that workaround code may now be redundant or conflict with the fix.