[
https://issues.apache.org/jira/browse/WW-5632?focusedWorklogId=1024452&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1024452
]
ASF GitHub Bot logged work on WW-5632:
--------------------------------------
Author: ASF GitHub Bot
Created on: 10/Jun/26 11:41
Start Date: 10/Jun/26 11:41
Worklog Time Spent: 10m
Work Description: lukaszlenart opened a new pull request, #1735:
URL: https://github.com/apache/struts/pull/1735
## Summary
Hardens Struts against [Apache Commons
FileUpload](https://commons.apache.org/proper/commons-fileupload/) milestone
(`-M`) binary-incompatibility.
[WW-5615](https://issues.apache.org/jira/browse/WW-5615) (#1584) fixed the
reported `NoSuchMethodError` symptom for 7.2.0 by adapting to the renamed M5
setters; this PR closes the underlying *class of failure* it left open.
- **Manage both artifacts (A1)** — introduce a single
`commons-fileupload2.version` property and manage *both*
`commons-fileupload2-core` and `commons-fileupload2-jakarta-servlet6` at it in
`parent/pom.xml`. The volatile setters
(`setMaxSize`/`setMaxFileCount`/`setMaxFileSize`) live in `-core`, which was
previously **unmanaged** — so a transitive dep could pull a mismatched `-core`
milestone and reproduce the crash even with `-jakarta-servlet6` pinned.
- **Activate a scoped enforcer (A2)** — the `maven-enforcer-plugin` rule was
configured only in `<pluginManagement>` and never actually ran. Bind it into
the active build with a fileupload-scoped `bannedDependencies` rule (single
source of truth via the property, actionable `<message>`), so any divergent
commons-fileupload2 version fails the build early.
- **Runtime guard (B)** — a once-per-JVM reflective check in
`AbstractMultiPartRequest` throws a clear `StrutsException` reporting the
`-core`/`-jakarta-servlet6` version skew instead of an opaque deep-stack
`NoSuchMethodError`. This is the only protection that reaches downstream
consumer runtimes the build-time enforcer can't.
Fixes [WW-5632](https://issues.apache.org/jira/browse/WW-5632)
## Test Plan
- [x] `mvn test -DskipAssembly -pl core` — BUILD SUCCESS, 2957 tests, 0
failures
- [x] New unit tests `AbstractMultiPartRequestApiCheckTest` (compatible
class passes; incompatible stub throws `StrutsException` with actionable
message)
- [x] Enforcer verified: passes on aligned tree; fails with the custom skew
message when `-core` is forced to a different milestone
- [x] `jakartaee11` profile unaffected (it does not override
`commons-fileupload2.version`)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1024452)
Remaining Estimate: 0h
Time Spent: 10m
> Harden commons-fileupload2 dependency against milestone binary-incompatibility
> ------------------------------------------------------------------------------
>
> Key: WW-5632
> URL: https://issues.apache.org/jira/browse/WW-5632
> Project: Struts 2
> Issue Type: New Feature
> Components: Core Interceptors
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.2.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Background
> [WW-5615|https://issues.apache.org/jira/browse/WW-5615] fixed the
> {{NoSuchMethodError}} caused by Apache Commons FileUpload 2.0.0-M5 renaming
> {{setSizeMax}} -> {{setMaxSize}} (and friends), shipped in 7.2.0 via
> [#1584|https://github.com/apache/struts/pull/1584].
> That fix addressed the *symptom* for one milestone bump but not the
> underlying *class of failure*.
> h3. Problem
> Struts depends on _milestone_ ({{-M}}) builds of commons-fileupload2, which
> break binary compatibility between milestones. Three gaps remain on {{main}}:
> * The renamed setters ({{setMaxSize}}, {{setMaxFileCount}},
> {{setMaxFileSize}}) live in
> *{{commons-fileupload2-core}}* ({{AbstractFileUpload}}), but only
> {{commons-fileupload2-jakarta-servlet6}} is pinned in
> {{dependencyManagement}} — {{-core}} is unmanaged, so a transitive dependency
> can pull a mismatched {{-core}} milestone and reproduce the
> {{NoSuchMethodError}}.
> * The {{maven-enforcer-plugin}} {{dependencyConvergence}} rule sits only in
> {{<pluginManagement>}} and is never bound to an active {{<plugins>}} section,
> so it never runs — the build cannot catch a fileupload version skew.
> * Downstream consumer runtimes get an opaque, deep-stack
> {{NoSuchMethodError}} with no actionable guidance.
> h3. Proposed changes
> * *(A1)* Introduce a single {{commons-fileupload2.version}} property and
> manage *both* {{commons-fileupload2-core}} and
> {{commons-fileupload2-jakarta-servlet6}} at that version in
> {{parent/pom.xml}}, forcing a matched {{-core}} version across the reactor.
> * *(A2)* Activate {{maven-enforcer-plugin}} with a fileupload-scoped
> {{bannedDependencies}} rule that fails the build on any commons-fileupload2
> version other than the pinned one (narrow scope, near-zero blast radius).
> * *(B)* Add a once-per-JVM reflective guard in {{AbstractMultiPartRequest}}
> that throws a clear {{StrutsException}} reporting the {{-core}} vs
> {{-jakarta-servlet6}} version skew instead of an opaque
> {{NoSuchMethodError}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
