You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Lukasz Lenart (Jira)" <ji...@apache.org> on 2026/06/10 11:17:00 UTC
[jira] [Updated] (WW-5632) Harden commons-fileupload2 dependency against milestone binary-incompatibility
[ https://issues.apache.org/jira/browse/WW-5632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukasz Lenart updated WW-5632:
------------------------------
Description:
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}}.
was:
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}}.
> 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
>
>
> 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)