Lukasz Lenart created WW-5632:
---------------------------------

             Summary: 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
             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)

Reply via email to