[jcastro-dotcms]

Summary

Minor/patch dependency upgrades, same shape as #37904.

Library	From	To	Where
log4j (log4j-api, log4j-core, log4j-1.2-api, log4j-jcl, log4j-slf4j2-impl, log4j-appserver)	2.23.1	2.25.5	bom/logging (webapp WEB-INF/lib and Tomcat log4j2/lib)
jsoup	1.21.1	1.23.2	bom/application
log4j (log4j-api, log4j-core, log4j-slf4j2-impl, embedded)	2.20.0	2.25.5	Tika OSGi bundle
jsoup (embedded, transitive via tika-parser-code-module)	1.22.2	1.23.2	Tika OSGi bundle
slf4j-api (embedded, transitive via log4j-slf4j2-impl)	2.0.6	2.0.17	Tika OSGi bundle

Changes

• bom/logging/pom.xml: log4j.version 2.23.1 → 2.25.5.
• bom/application/pom.xml: jsoup.version 1.21.1 → 1.23.2.
• independent-projects/core-plugins/tika-plugin/pom.xml:
  • dependencyManagement imports log4j-bom 2.25.5 and manages org.jsoup:jsoup 1.23.2 (same pattern as the existing jackson-bom import); the hardcoded log4j-slf4j2-impl 2.20.0 version is dropped.
  • Two maven-bundle-plugin instructions, _bundleannotations and _removeheaders. log4j 2.25 jars carry OSGi bundle annotations (their own Bundle-Activator, capabilities and package exports). bnd applies them to every class in the bundle, embedded jars included, which fails the build with a three-class Bundle-Activator header and would export every log4j package from the Tika bundle. The instructions limit annotation processing to our own classes and drop the computed Export-Package, so the bundle manifest keeps the same header set as today: one activator, no exports, Require-Capability unchanged.
  • Import-Package gains org.osgi.framework.wiring. log4j 2.25 resolves its providers through the OSGi wiring API when it runs inside a bundle, and without that import the bundle activator failed to initialize its logger, so the Tika service never registered and file metadata extraction logged errors on every asset. Found on a local stack; Felix exports the package from the system bundle.

Notes for reviewers

• The first commit targeted 2.25.4; the second moves to 2.25.5, the newest patch on the same line, which carries one more log4j-api fix. Its release notes list only fixes (rolling-file createOnDemand, JSON/XML encoding of messages, stack-trace rendering, a configuration-source resource leak); no configuration or OSGi changes.

• No Java changes. Core does not use the Log4j 1.x API and changes log levels through the log4j-core classes directly, so the 2.24 change that stops the 1.x and JUL bridges from reconfiguring core does not apply.

• log4j 2.25 changed the default exception rendering and sends the status logger to stderr. Our log4j2.xml sets an explicit %xEx{filters(...)} pattern; startup output was compared on a local stack (see Tests).

• jsoup 1.22/1.23 changed parser defaults (depth limit 512, noscript parsed into the DOM, trailing comments after </body> kept under html). The classes core uses (Jsoup, Document, Element, Elements, Node, TextNode, Comment) are unchanged.

• The host-exported package versions in osgi-extra.conf still read 2.20.0 for org.apache.logging.*; bnd-generated import ranges ([2.20,3)) keep resolving, so that file is untouched.

Tests

• ./mvnw install -pl :dotcms-core --am -DskipTests -Dmaven.build.cache.enabled=false: all 13 modules pass; openapi.yaml unchanged.
• dependency:tree: core resolves log4j 2.25.5 and jsoup 1.23.2; the Tika bundle resolves log4j-api/core/slf4j2-impl 2.25.5 and jsoup 1.23.2.
• Unit tests: 217 pass across the classes that use jsoup or the log4j-core API (LoggerTest, StringUtilsTest, TiptapHtmlTest, TiptapHtmlRichNodeTest, LongTextPreviewStrategyTest, HtmlMinifierIntegrityTest, AIViewToolErrorHandlerTest, ContentFactoryIndexOperationsPhaseRoutingTest, ReindexThreadUnitTest, RuleActionRefusedNameTest).
• Local image: WEB-INF/lib and Tomcat log4j2/lib ship 2.25.5, jsoup 1.23.2; the Tika bundle embeds the new versions. Its manifest has the same header set as the bundle in 26.10.29-01 (single activator, no exports, same Require-Capability), plus the org.osgi.framework.wiring import.
• Local stack from that image vs. a stack from 26.10.29-01, same starter: identical startup log shape (same error and warning kinds, levels unchanged), Tika bundle starts and file metadata extraction returns the same fields, page render identical, GET/PUT /api/v1/logger level changes round-trip. The only visible difference is eight log4j status-logger lines on stderr at startup (2.25 writes the status logger to stderr; our log4j2.xml sets status="INFO").

Risk

Low. Patch/minor upgrades within the same major lines; no API changes in the code paths core uses. The Tika bundle manifest is byte-for-byte the same header set as the current release, verified by diffing against the shipped com.dotcms.tika-26.10.29-01.jar.

This PR fixes: #37975

🤖 Generated with Claude Code

[claude]

Claude finished @jcastro-dotcms's task in 1m 33s —— View job

---

PR Review: bump log4j 2.25.5 & jsoup 1.23.2

• Gather context (diff, poms)
• Review bom changes
• Review Tika plugin OSGi changes
• Post findings

New Issues

• 🟡 Medium: bom/logging/pom.xml:18-19 — log4j.version moves to 2.25.5 while slf4j.version stays 2.0.9. log4j-slf4j2-impl:2.25.5 declares a compile dependency on slf4j-api:2.0.17, but bom/logging pins slf4j-api to 2.0.9, so the core webapp runs the 2.25.5 binding against an older slf4j API than it was built against. The 2.0.x line is binary-compatible so this is almost certainly fine (and the version skew predates this PR), but the gap widens here. Assumption: slf4j 2.0.x maintains forward binding compatibility. What to verify: that the webapp's WEB-INF/lib resolves a single slf4j-api and that SLF4J logging still binds to log4j at startup (the local-stack startup-log comparison in the PR notes already covers this — worth confirming no SLF4J: Failed to load class / provider-mismatch lines appeared).

Notes (non-blocking, no action required)

• independent-projects/core-plugins/tika-plugin/pom.xml:191 — overriding _removeheaders replaces the maven-bundle-plugin's built-in default rather than appending to it. The comment correctly identifies Include-Resource,Private-Package as the plugin defaults and re-adds them alongside Export-Package, and the PR notes state the resulting manifest was diffed byte-for-byte against the shipped com.dotcms.tika-26.10.29-01.jar. That verification is the right mitigation for this class of change — good.
• tika-plugin/pom.xml:181,191 — Export-Package is both emptied (<Export-Package />) and listed in _removeheaders. Redundant but harmless; it guarantees the computed export list from the log4j 2.25 bundle annotations is dropped.
• tika-plugin/pom.xml:88-92 — dropping the hardcoded log4j-slf4j2-impl version in favor of the imported log4j-bom is the cleaner pattern and matches the existing jackson-bom import above it. Good.
• tika-plugin/pom.xml:176 — adding org.osgi.framework.wiring to Import-Package is consistent with the embedded-only (not imported) log4j design; Felix exports the package from the system bundle, so the range resolves.

Summary

The change is well-scoped: all log4j artifacts in bom/logging key off the single ${log4j.version} property, so the one-line bump is complete, and the jsoup bump is a single property in bom/application. The Tika OSGi work (bundle-annotation scoping, header removal, wiring import) is non-obvious but each instruction is explained in-line and backed by the documented manifest diff and local-stack validation. No blocking issues — the one Medium is a verification item, not a defect I can prove from the diff.
· issue-37975-bump-log4j-and-jsoup-core-and-tika-bundle

[mbiuki]

Security assessment

CVSS 4.0	8.7 High · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Source	Same as the issue it fixes (#37975); NVD CVSS 4.0 vector (CVE-2026-75140)
Priority	P2 · due 2026-11-28 (one month, 30 days from 2026-10-29) · project #7 (dotCMS - Product Planning): P2 - High

Why: Carries the score and priority of the issue it fixes (#37975).

Labels: added Team : Security, CVSS 4.0 : 8.7.

Automated triage by the dotCMS Security team (Claude), 2026-10-30. To override, change the project's Priority field or the CVSS label. The next refresh keeps a manual change.