chore(core): Update netty lib, remove pgjdbc-ng and PostgresPubSubImpl (#37592)

[wezell]

Proposed Changes

• Delete PostgresPubSubImpl and PgNgDataSourceUrl — dead code superseded by JDBCPubSubImpl (vanilla postgres driver, PubSubListener with vanilla postgres #26019). DotPubSubProviderLocator has defaulted to JDBCPubSubImpl since, and nothing in the repo sets DOT_PUBSUB_PROVIDER_OVERRIDE to PostgresPubSubImpl.
• Delete their tests and deregister PostgresPubSubImplTest from MainSuite2a / MainSuite2b (a stale entry there would compile but fail the suite).
• Drop the com.impossibl.pgjdbc-ng:pgjdbc-ng dependency from dotCMS/pom.xml and its version from bom/application/pom.xml.
• Replace the codebase's only Netty import — io.netty.util.NetUtil.createByteArrayFromIpAddressString() in HttpRequestDataUtil#getIpAddress — with Guava InetAddresses.forString(). Guava is already a direct compile dependency. throws UnknownHostException is preserved because 6 call sites catch it.
• Make DOT_PUBSUB_PROVIDER_OVERRIDE fail soft: an override that cannot be loaded or constructed now logs a warning and falls back to JDBCPubSubImpl instead of throwing DotRuntimeException at startup.
• Replace the six piecemeal Netty pins with an io.netty:netty-bom import, and bump 4.1.118.Final → 4.1.138.Final (latest 4.1.x).

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

Closes #37592. Follow-up to the pgjdbc-ng discussion on #37588.

Why: pgjdbc-ng was the only remaining compile-scope, non-Azure/non-AWS source of Netty, transitively bringing 4.1.63 while langchain4j-azure-open-ai brought 4.1.118. That conflict is what the six Netty BOM pins existed to paper over.

Removing PostgresPubSubImpl is no longer a breaking change. Deployments that had pointed DOT_PUBSUB_PROVIDER_OVERRIDE at it now degrade to JDBCPubSubImpl with a warning instead of failing to start. The fallback covers:

Failure	Handled
class missing / no longer on the classpath	✅
no no-arg constructor	✅
constructor throws	✅
class does not implement DotPubSubProvider	✅
the fallback target is itself unusable	rethrows — nothing left to fall back to

Also replaced the deprecated Class.newInstance() with getDeclaredConstructor().newInstance(), and documented the behaviour in dotmarketing-config.properties.

Netty version bump

The six individual pins only covered netty-common/-buffer/-transport/-resolver/-codec/-handler, so the rest of the tree still resolved to whatever each consumer asked for:

Module	Before	After
netty-common…netty-handler	4.1.118	4.1.138
netty-resolver-dns (reactor-netty)	4.1.112	4.1.138
netty-codec-http2 (azure)	4.1.132	4.1.138
netty-transport-classes-epoll (awssdk)	4.1.130	4.1.138
netty-tcnative-boringssl-static	2.0.70	2.0.84

Importing netty-bom manages all 60 Netty artifacts at one version, which removes that skew — mixed Netty modules on a single classpath fail at runtime with NoSuchMethodError. Side effect: tcnative follows the BOM to 2.0.84.Final.

CVEs addressed

The bump resolves all six Netty findings from the security scan. Every one is fixed in a version below where we now land (all Netty artifacts are 4.1.138.Final):

CVE	Artifact	Scan severity	NVD severity	Fixed in	Covered by 4.1.138
CVE-2026-42579	netty-codec-dns	Critical	Critical	4.1.133	✅
CVE-2026-47691	netty-resolver-dns	Critical	Critical	4.1.135	✅
CVE-2026-45674	netty-resolver-dns	Critical	High	4.1.135	✅
CVE-2026-42584	netty-codec-http	Critical	High	4.1.133	✅
CVE-2026-42581	netty-codec-http	Critical	Medium	4.1.133	✅
CVE-2026-50010	netty-handler	High	High	4.1.135	✅

Fixed versions checked against the NVD API (services.nvd.nist.gov/rest/json/cves/2.0). Two entries disagree on severity with the scan output; recorded rather than reconciled.

Worth stressing: before this bump the tree was not merely 4.1.118. The artifacts the six hand-written pins did not cover resolved to 4.1.112 (netty-resolver-dns), 4.1.130 (netty-transport-classes-epoll) and 4.1.132 (netty-codec-http2) — all below the fix thresholds. Importing netty-bom is what makes the remediation complete: bumping the six pins alone would have left netty-resolver-dns at 4.1.112, still exposed to CVE-2026-47691 and CVE-2026-45674.

CI status — all green

Every check passes, including MainSuite 1a/1b/2a/2b/3a, all Postman splits, JVM unit tests, CLI/E2E/Karate, the AI review and the rollback-safety checks.

The first run reported failures in MainSuite 1a/1b/2a/2b/3a, Postman Default Split and Postman Category Content. Those were flaky, not from this change: unrelated open PRs #37591 and #37589 were failing the identical suites on the same runners at the same time (#37589 failed MainSuite 2a too), and simply re-running the failed jobs cleared every one of them. Observed causes were environmental — StoryBlockMapTest NPEs on a null HttpSession in the Velocity toolbox, and Task240306MigrateLegacyLanguageVariablesTest / ExperimentAPIImpIntegrationTest timing out at ~65s. The logs also show dotpubsub.JDBCPubSubImpl - Starting to listen for Postgres notifications running normally under this PR.

Verification

• dependency:tree → every io.netty artifact resolves to 4.1.138.Final (16 modules), tcnative to 2.0.84.Final; pgjdbc-ng count 0
• test -pl :dotcms-core -Dtest=DotPubSubProviderLocatorTest,HttpRequestDataUtilTest,CacheTransportTopicTest → Tests run: 17, Failures: 0, Errors: 0
• test-compile -pl :dotcms-core → BUILD SUCCESS
• test-compile -pl :dotcms-integration → BUILD SUCCESS, 0 errors, MainSuite2a/MainSuite2b compiled
• Zero residual references to com.impossibl.*, PostgresPubSubImpl, PgNgDataSourceUrl, or io.netty.util

⚠️ The version bump is the least-proven part of this PR. Compilation and unit tests do not exercise the Azure/Vertex/AWS SDK HTTP paths that actually use Netty at runtime, nor BoringSSL native loading under the new tcnative. A run against a real Azure OpenAI (or SQS) integration is worth doing before merge. It stays in this PR as its own commit (b6a18e74b1) so it can be reverted independently if it needs backing out.

Netty does not fully disappear — it stays on the classpath via azure-core-http-netty (langchain4j) and netty-nio-client (AWS SDK SQS).

Behavioral notes

• getIpAddress previously returned loopback (127.0.0.1) when the remote address was unparseable; that fallback is unchanged. Guava's parser accepts IPv4, IPv6 and scoped IPv6 (fe80::1%eth0), verified directly against guava-32.0.1-jre.
• POSTGRES_PUBSUB_JDBC_URL and the jdbc:pgsql:// URL scheme become unused after this change.

Screenshots

N/A — backend/dependency change.

This PR fixes: #37592

[claude]

Claude finished @wezell's task in 1m 34s —— View job

---

Code Review

Reviewed the full diff against origin/main. This is a clean dead-code removal + dependency consolidation. I traced the two behavioral changes carefully:

DotPubSubProviderLocator.resolveProvider — fallback logic is correct. Try.of catches Throwable (vavr), so it covers NoClassDefFoundError/ClassNotFoundException (class off classpath), NoSuchMethodException (no no-arg ctor), the wrapped constructor exception, and ClassCastException (not a DotPubSubProvider). The defaultClazz.equals(pubsubClazz) guard correctly rethrows when the default is itself the unusable target — no infinite/no-op fallback. Test matrix covers all five paths plus the rethrow.

HttpRequestDataUtil.getIpAddress — InetAddresses.forString() is a pure parse (no DNS), matching the old NetUtil behavior; both return an unresolved-host InetAddress. The empty/null/unparseable → loopback fallback is preserved, and throws UnknownHostException is retained for the 6 catching call sites. IllegalArgumentException is the correct Guava exception to catch here.

Verified:

• Zero residual references to PostgresPubSubImpl, PgNgDataSourceUrl, com.impossibl.*, io.netty.util, POSTGRES_PUBSUB_JDBC_URL, jdbc:pgsql anywhere in the repo.
• Both the import and the @SuiteClasses entry removed in MainSuite2b; MainSuite2a only had a stale (unused) import, so import-only removal there is correct.
• netty-bom import replaces the six per-artifact pins with ${netty.version} = 4.1.138.Final, consistent with commit b6a18e74. BOM import is the right mechanism to force a single Netty version across the transitive trees (azure/aws/reactor).
• Dependency declaration in dotCMS/pom.xml and version in bom/application/pom.xml both removed — follows the repo's version-management rule.

New Issues

No issues found.

---

• Gather PR diff and context
• Review DotPubSubProviderLocator fallback logic
• Review HttpRequestDataUtil Netty→Guava swap
• Review pom/dependency changes
• Review test changes
• Post review

Note: the ❌ Linked Issue Needs Team Label check is unrelated to code — issue #37592 just needs a Team : * label applied.
· issue-37592-remove-pgjdbc-ng

[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

Removal of pgjdbc-ng/PostgresPubSubImpl is complete with no residual references, Netty BOM alignment covers all modules, Guava IP parsing preserves loopback fallback with no DNS, and soft-fallback to JDBCPubSubImpl is intentional, logged and tested.

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

The removal is complete: no residual references to pgjdbc-ng, PostgresPubSubImpl, PgNgDataSourceUrl, or NetUtil remain in build files or source. The new resolveProvider fallback logic is correct (it rethrows when the default provider itself fails, and tests cover all paths), the Guava InetAddresses swap preserves IP-literal parsing and the loopback fallback, and the Netty BOM import is a valid consolidation. Test suites were updated consistently.

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

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

[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}