Skip to content

WW-5632 Harden commons-fileupload2 dependency against milestone binary-incompatibility#1735

Open
lukaszlenart wants to merge 6 commits into
mainfrom
WW-5632-fileupload2-milestone-hardening
Open

WW-5632 Harden commons-fileupload2 dependency against milestone binary-incompatibility#1735
lukaszlenart wants to merge 6 commits into
mainfrom
WW-5632-fileupload2-milestone-hardening

Conversation

@lukaszlenart

Copy link
Copy Markdown
Member

Summary

Hardens Struts against Apache Commons FileUpload milestone (-M) binary-incompatibility. 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

Test Plan

  • mvn test -DskipAssembly -pl core — BUILD SUCCESS, 2957 tests, 0 failures
  • New unit tests AbstractMultiPartRequestApiCheckTest (compatible class passes; incompatible stub throws StrutsException with actionable message)
  • Enforcer verified: passes on aligned tree; fails with the custom skew message when -core is forced to a different milestone
  • jakartaee11 profile unaffected (it does not override commons-fileupload2.version)

🤖 Generated with Claude Code

lukaszlenart and others added 5 commits June 10, 2026 13:16
Design for hardening the commons-fileupload2 dependency against
milestone binary-incompatibility (manage -core, activate a scoped
enforcer rule, add a runtime API guard in AbstractMultiPartRequest).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ning

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a-servlet6

Pin both commons-fileupload2 artifacts to a single
commons-fileupload2.version property so the volatile -core API can no
longer skew from -jakarta-servlet6 in the reactor.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Activate maven-enforcer-plugin (previously dormant in pluginManagement)
with a fileupload-scoped bannedDependencies rule so any divergent
commons-fileupload2 version fails the build early.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…2 API

Verify once per JVM that the fileupload size-limit setters exist and
throw a clear StrutsException reporting the core/jakarta version skew,
replacing an opaque deep-stack NoSuchMethodError in downstream runtimes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Resolve Sonar java:S2696 (instance method writing a static field) by
making ensureFileUploadApiVerified() static; verification is JVM-global.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant