chore(deps): bump jackson, commons-fileupload, grpc and AWS SDK v1 (#36546)

[sfreudenthaler]

Warning

• Upload filenames: commons-fileupload 1.6.0 rejects upload parts whose headers exceed 512 bytes, which a very long or non-ASCII filename could hit. That limit is the security fix itself, so I kept it. It affects the legacy portlet uploads and the push-publish bundle upload. The PR description calls it out for reviewers.
• jackson 2.18 is a minor upgrade but includes a rewrite of how properties are detected, so watch CI for serialization regressions.

Summary

Minor/patch dependency upgrades for libraries with published security fixes.

Library	From	To	Where
jackson (core, databind)	2.17.2	2.18.11	bom/application
jackson (core, databind)	2.21.3	2.21.7	Tika OSGi bundle
commons-fileupload	1.5	1.6.0	bom/application
grpc (grpc-bom pin)	1.71.0 (transitive)	1.75.0	bom/application
aws-java-sdk v1	1.12.488	1.12.797	bom/application (no longer depends on software.amazon.ion:ion-java)

Covers the remaining scope of #36548 (its netty part already landed in #37593).

Notes for reviewers

• commons-fileupload 1.6.0 changes the signature of FileUploadBase.createItem(Map, boolean). The overrides in LiferayFileUpload and LiferayDiskFileUpload stopped compiling, so I removed them. They're dead code: parseRequest hasn't called that method since 1.3 (it goes through FileItemFactory.createItem).
• commons-fileupload 1.6.0 adds a default per-part header limit of 512 bytes. This affects the legacy portlet multipart path (UploadServletRequest) and the push-publish bundle upload (RemotePublishAjaxAction). A part whose headers exceed 512 bytes (e.g. a very long or multibyte filename) is now rejected. I left the upstream default in place.
• grpc is pinned to 1.75.x. 1.76+ needs guava 33.4+, and dotCMS pins guava to 32.0.1-jre. 1.75.0 has the same guava/protobuf requirements as the 1.71.0 we ship today.
• jackson 2.18 is a minor upgrade that includes the property-introspection rewrite. CI is the main check for serialization regressions.

Verification

• ./mvnw compile -pl :dotcms-core passes; openapi.yaml unchanged
• dependency:tree confirms the resolved versions above, and ion-java is no longer on the classpath
• The Tika bundle embeds jackson-core/jackson-databind 2.21.7

Closes: #36546

🤖 Generated with Claude Code

https://claude.ai/code/session_017K9XDfPM8s7XjLDG2V4LnN

This PR fixes: #36546

[dotCMS-Machine-User]

✅ dotbot review: all reviewer models (meta/muse-spark-1.3, ~z-ai/glm-latest) agree — patch is correct.

_{approved automatically by dotbot}

[claude]

Claude finished @erickgonzalez's task in 1m 57s —— View job

---

PR Review — dependency bumps (jackson, commons-fileupload, grpc, AWS SDK v1)

• Gather context (diff, affected files)
• Verify removed createItem overrides are dead code
• Verify dependency/BOM ordering and version pins
• Post review

---

I reviewed the diff against origin/main. Verification notes below.

New Issues

• 🟡 Medium: dotCMS/src/main/webapp/html/portal/upload_progress.jsp:28 — The PR description and both dotbot reviewers state "no remaining code reads the FILE_NAME session attribute." That is not accurate: this legacy JSP reads session.getAttribute(LiferayDiskFileUpload.FILE_NAME) and renders it (:112). The removed createItem override in LiferayDiskFileUpload was the only writer of that attribute.

  I traced the call path and the removal does not change observable behavior: UploadServletRequest (:80-85) builds a LiferayDiskFileUpload and calls parseRequest, which delegates to ServletFileUpload.parseRequest. Since commons-fileupload 1.3 that path creates items via FileItemFactory.createItem, never FileUploadBase.createItem(Map, boolean) — so the override was already dead and the attribute was already never set. upload_progress.jsp has therefore been rendering an empty filename regardless of this PR. So the dead-code conclusion holds; only the stated justification is imprecise.

  Assumption: the legacy Liferay portal upload-progress page still relies on this attribute at runtime.
  What to verify: whether upload_progress.jsp is still reachable and whether the empty-filename display there is pre-existing (it is, from the code) and acceptable. No action required for merge.

Verified / no issues

• ✅ bom/application/pom.xml:82-90 — grpc-bom import is ordered before langchain4j-bom (:92), and grpc.version=1.75.0 is defined (:35). The 1.75.x pin rationale (guava 32.0.1-jre) is sound.
• ✅ AWS SDK v1 → 1.12.797: no code references com.amazon.ion / software.amazon.ion, so dropping the transitive ion-java is safe.
• ✅ LiferayFileUpload / LiferayDiskFileUpload: removed overrides are confirmed unreachable; remaining removeAttribute(FILE_NAME) and the _ses field are still used, so no unused-field/compile issues.
• ✅ independent-projects/core-plugins/tika-plugin/pom.xml:35-42 — com.fasterxml.jackson:jackson-bom:2.21.7 import coordinates are correct; this module doesn't inherit bom/application, so a local pin is the right mechanism.
• ✅ Versions added to bom/application/pom.xml only (and the tika sub-module's own dependencyManagement), per repo convention — nothing in dotCMS/pom.xml.

The two intentional behavior changes the author already called out — commons-fileupload 1.6.0's 512-byte per-part header limit, and jackson 2.18's property-introspection rewrite — are not defects; they're correctly flagged for CI/QA attention. The header limit in particular is a real functional change for very long or multibyte upload filenames on the legacy portlet and push-publish bundle paths, worth a targeted upload smoke test before release.

No blocking issues.
· branch issue-36546-dependency-upgrades

[github-actions]

dotbot code review:

• Reviewer: meta/muse-spark-1.3 (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

Dependency-only bumps with compile fixes; removed createItem overrides were unreachable via the FileItemFactory path, header-limit retention is intentional hardening called out in the PR, and version/BOM ordering is correct with no tracked callers broken.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · meta/muse-spark-1.3 · medium}

[github-actions]

dotbot code review:

• Reviewer: ~z-ai/glm-latest (medium)
• Overall: patch is correct
• New findings this run: 0
• Prior unresolved dotbot findings still relevant: 0
• Active findings total: 0

Dependency version bumps plus removal of dead createItem overrides. In commons-fileupload 1.5, item creation goes through the FileItemFactory (LiferayFileItemFactory already returns LiferayFileItem), so the removed overrides were unreachable; the FILE_NAME session attribute is never read by remaining code (only removed), so behavior is preserved. The grpc-bom import ordering before langchain4j-bom and the tika-plugin jackson pin are intentional and documented in the diff.

Tip: comment with "/dotbot address comments" to attempt automated fixes for unresolved review threads.

_{reviewed by dotbot · ~z-ai/glm-latest · medium}

[github-actions]

⚠️ AI review failed

Claude did not produce a review — the backend call errored before generating any output (provider: anthropic-bedrock, model: global.anthropic.claude-sonnet-5). This usually means the model has no Bedrock access grant in the target account, or the model ID is invalid — not a problem with this PR.

_{Run: #37484553261}

[github-actions]

🐳 PR Docker test image

Latest build for commit c430b21 pushed to dotcms/dotcms-test:

docker pull dotcms/dotcms-test:pr-37904-issue-36546-dependency-upgrades
docker pull dotcms/dotcms-test:pr-37904-issue-36546-dependency-upgrades_c430b21

[sfreudenthaler]

Pre-merge QA ✅

Tested the PR: docker image build of this branch (a48321f, the PR merged into current main) on a temporary cloud environment cloned from our staging data.

Area	Check	Result
jackson 2.18 (core)	Content-type list, content search, and GraphQL BlogCollection return real data	✅
jackson 2.18 (core)	Create and publish webPageContent via workflow API; validation errors come back as well-formed JSON	✅
Tika / jackson 2.21.7	PDF uploaded as FileAsset: detected as application/pdf, and full-text search finds a word that only exists inside the PDF (negative control returns nothing)	✅
commons-fileupload 1.6.0	Legacy multipart path (MainServlet → UploadServletRequest → LiferayDiskFileUpload) parses a normal upload; no runtime errors from the removed createItem overrides	✅
commons-fileupload 1.6.0	A part with a 617-char filename is rejected by the new 512-byte part-header limit (SizeLimitExceededException logged); the request completes and the server stays healthy	✅ (intended)
UI	Pages and Content Drive render; test content shows as Published; no browser console errors	✅
Logs	No NoSuchMethodError, ClassNotFoundException, or Jackson binding errors during the run	✅
AWS SDK v1 / grpc (Vertex)	Not exercised: the environment has no S3/Rekognition or Vertex configuration	⚠️ not covered

The claude-rollback-safety-check failures on this PR are the reviewer hitting its turn limit (num_turns: 20, is_error: true), not an unsafe verdict.

[sfreudenthaler]

@ihoffmann-dot heads up that this patch might impact dotai. where’s the best place to test that