What Is New in Struts 6.11
| Category | Highlights |
|---|---|
| Improvements |
|
| Bug Fixes |
|
| Dependency Updates |
|
What performance issue does Struts 6.11 fix in SecurityMemberAccess?
Struts 6.11 resolves a performance problem in SecurityMemberAccess, the class responsible for enforcing OGNL member-access rules on every property access the framework evaluates. In practice, this class sits directly in the hot path of form binding and result rendering, so any inefficiency here shows up as latency on nearly every request that touches OGNL expressions.
The fix, tracked as WW-5630, was cherry-picked back into the 6.x line rather than held for a future major release, which signals the Struts team considered the regression significant enough for immediate backport. Most teams running high-traffic actions with heavy form binding or complex value stack expressions should see reduced CPU overhead after upgrading, particularly under load.
Watch out for this if you have custom SecurityMemberAccess subclasses or interceptors that wrap OGNL evaluation. Re-test any custom security member-access logic against 6.11 to confirm your overrides still behave as expected with the underlying performance changes.
How does Struts 6.11 change input length limits on request bodies?
Struts 6.11 applies input length limits consistently when reading request bodies, closing gaps where certain request-parsing paths were not previously constrained the same way as others. This matters if your application accepts large multipart uploads or sizable form payloads, since inconsistent limits can be exploited as a resource-exhaustion vector or can simply cause confusing behavior between different endpoint types.
The change, tracked as WW-5666, does not add a new configuration surface on its own; it tightens enforcement of limits that already exist in the framework so that request body parsing behaves predictably regardless of which internal code path handles a given request.
- Review any custom
MultiPartRequestimplementations for assumptions about unbounded input. - If you rely on very large request bodies for legitimate use cases (bulk data import endpoints, for example), confirm your existing size configuration still accommodates them after upgrading.
- Run your integration test suite against realistic payload sizes before rolling this out to production.
What changed in the localized-text provider caching in Struts 6.11?
Struts 6.11 makes the localized-text provider caches size-bounded and aligns how the framework resolves the request locale, addressed under WW-5668. Previously, these caches could grow without an explicit ceiling, which in long-running applications with many locales or dynamically generated resource keys could lead to gradually increasing memory usage.
In practice, this affects applications that serve many languages or that generate localization keys programmatically (for example, keyed by user input or dynamic field names). Bounding the cache size protects against unbounded memory growth, at the cost of potential cache eviction under very high key cardinality, which is a reasonable tradeoff for most production deployments.
The aligned request-locale resolution also means locale selection should now behave more predictably and consistently across different parts of the framework that previously may have resolved locale slightly differently. Teams with custom locale-resolution logic should verify their behavior still matches expectations after upgrading.
What dependency updates ship with Struts 6.11?
Struts 6.11 bundles routine dependency bumps rather than a major library upgrade, keeping the framework current with upstream security and bug fixes. The most notable are jackson.version moving from 2.21.4 to 2.22.1 across two incremental bumps, and commons-logging:commons-logging moving from 1.3.6 to 1.4.0.
Also included is a minor log4j2.version bump from 2.26.0 to 2.26.1. These are largely maintenance updates and, in practice, most applications will not need any code changes because of them. Build-tooling dependencies such as maven-surefire-plugin, maven-failsafe-plugin, maven-dependency-plugin, and jacoco-maven-plugin were also bumped, but these only affect the build process, not runtime behavior.
<properties>
<jackson.version>2.22.1</jackson.version>
<log4j2.version>2.26.1</log4j2.version>
</properties>If your project overrides these versions in its own POM, double check for conflicts after upgrading the parent Struts version.
FAQ
Does upgrading to Struts 6.11 require changes to existing actions?
Most applications will not need code changes, since the release focuses on internal performance, caching, and input-handling improvements rather than API changes.
What is WW-5630 in Struts 6.11?
WW-5630 is a fix for a performance issue in SecurityMemberAccess, the class that enforces OGNL member-access rules, and it was cherry-picked into the 6.x line for immediate availability.
Does Struts 6.11 change how large uploads are handled?
Yes, WW-5666 applies input length limits consistently when reading request bodies, so teams accepting large multipart uploads should verify their size configuration still works after upgrading.
Why were the localized-text provider caches made size-bounded?
To prevent unbounded memory growth in long-running applications that serve many locales or generate localization keys dynamically, addressed under WW-5668.
Are there breaking changes in Struts 6.11?
No breaking changes are documented for this release; the changes are internal performance and consistency improvements alongside routine dependency updates.
What dependency versions changed in Struts 6.11?
Jackson was bumped through 2.22.1, commons-logging moved to 1.4.0, and log4j2 moved to 2.26.1, for example jackson.version is now set to 2.22.1 in the POM.