[oscerd]

Jira: https://issues.apache.org/jira/browse/CAMEL-25964

Problem

In VertxHelper.setupSSLOptions(...) (camel-vertx-common), Vert.x TCPSSLOptions are configured from SSLContextParameters.
When TrustManagersParameters is configured with a standalone TrustManager via setTrustManager(...) without a KeyStore, createTrustManagerFactory(...) returns null because no keystore is present.

VertxHelper previously checked only whether:

if (sslContextParameters.getTrustManagers() != null &&
        sslContextParameters.getTrustManagers().getTrustManager() == TrustAllTrustManager.INSTANCE) {
    tcpsslOptions.setTrustOptions(TrustOptions.wrap(TrustAllTrustManager.INSTANCE));
}

Any other standalone TrustManager instance was discarded and not passed to tcpsslOptions.setTrustOptions(...). As a result, tcpsslOptions.getTrustOptions() remained null, and Vert.x fell back to its default trust configuration.

Change

• org.apache.camel.component.vertx.common.VertxHelper: Check whether sslContextParameters.getTrustManagers() != null && sslContextParameters.getTrustManagers().getTrustManager() != null. If present, wrap and set it using TrustOptions.wrap(trustManager). When no standalone TrustManager is supplied, call createTrustManagerFactory(camelContext, sslContextParameters) to configure TrustManagerFactoryOptions from the configured keystore.
• Upgrade guide 4.24: Added a note documenting that standalone TrustManager instances on SSLContextParameters are now applied in Vert.x components.

Tests

• Added VertxHelperTest in camel-vertx-common to test:
  • Standalone custom TrustManager is wrapped and applied.
  • TrustAllTrustManager.INSTANCE is wrapped and applied.
  • KeyStore-based TrustManagerFactory is applied when no standalone manager is set.
  • No trust options when none is configured.

Claude Code on behalf of oscerd

🤖 Generated with Claude Code

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[gnodet]

🔄 Backport Bot

This bugfix targets main and may need porting to:

• camel-4.22.x

Add a port/<branch> label to automatically create a backport PR for that branch.

Backport PRs will be created automatically on merge (once a port label is added). Comment /port to create them immediately.

ℹ️ If you push additional commits after /port, use /port again to update the port PRs.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-vertx/camel-vertx-common
• docs

ℹ️ Dependent modules were not tested because the total number of affected modules exceeded the threshold (50). Use the test-dependents label to force testing all dependents.

---

🔬 Scalpel shadow comparison — Scalpel: 26 of 707 tested, 2 compile-only — current: 26 all tested

Maveniverse Scalpel detected 26 affected modules (current approach: 26).

Skip-tests mode would test 26 modules (2 direct + 0 downstream), skip tests for 2 (generated code, meta-modules)

Modules Scalpel would test (26)

• camel-a2a ← depends on affected reactor module org.apache.camel:camel-platform-http-vertx
• camel-ibm-watsonx-ai ← depends on affected reactor module org.apache.camel:camel-vertx-websocket
• camel-jbang-mcp ← depends on affected reactor module org.apache.camel:camel-rest-openapi
• camel-jbang-plugin-mcp ← depends on affected reactor module org.apache.camel:camel-jbang-core
• camel-jbang-plugin-tui ← depends on affected reactor module org.apache.camel:camel-yaml-dsl-validator
• camel-jbang-plugin-validate ← depends on affected reactor module org.apache.camel:camel-yaml-dsl-validator
• camel-jsonpath ← depends on affected reactor module org.apache.camel:camel-platform-http-vertx
• camel-knative-http ← depends on affected reactor module org.apache.camel:camel-platform-http-vertx
• camel-launcher-container ← depends on affected reactor module org.apache.camel:camel-launcher
• camel-mcp-server ← depends on affected reactor module org.apache.camel:camel-openai
• camel-micrometer-prometheus ← depends on affected reactor module org.apache.camel:camel-platform-http-main
• camel-oauth ← depends on affected reactor module org.apache.camel:camel-vertx-http
• camel-observability-services ← depends on affected reactor module org.apache.camel:camel-micrometer-prometheus
• camel-openai ← depends on affected reactor module org.apache.camel:camel-platform-http-vertx
• camel-openapi-validator ← depends on affected reactor module org.apache.camel:camel-platform-http-vertx
• camel-platform-http-main ← depends on affected reactor module org.apache.camel:camel-platform-http-vertx
• camel-platform-http-vertx ← depends on affected reactor module org.apache.camel:camel-vertx-http
• camel-rest-openapi ← depends on affected reactor module org.apache.camel:camel-vertx-http
• camel-rest-postman ← depends on affected reactor module org.apache.camel:camel-vertx-http
• camel-semantic-openai ← depends on affected reactor module org.apache.camel:camel-openai
• camel-vertx ← depends on affected reactor module org.apache.camel:camel-vertx-common
• camel-vertx-common ← components/camel-vertx/camel-vertx-common/src/main/java/org/apache/camel/component/vertx/common/VertxHelper.java, components/camel-vertx/camel-vertx-common/src/test/java/org/apache/camel/component/vertx/common/VertxHelperTest.java, components/camel-vertx/camel-vertx-common/src/test/resources/jsse/truststore.jks, own pom components/camel-vertx/camel-vertx-common/pom.xml changed
• camel-vertx-http ← depends on affected reactor module org.apache.camel:camel-vertx-common
• camel-vertx-websocket ← depends on affected reactor module org.apache.camel:camel-vertx-common
• camel-yaml-dsl-validator ← depends on affected reactor module org.apache.camel:camel-catalog
• camel-yaml-dsl-validator-maven-plugin ← depends on affected reactor module org.apache.camel:camel-yaml-dsl-validator

Modules with tests skipped (2)

• camel-itest
• camel-yaml-dsl-deserializers

ℹ️ Shadow mode — Scalpel observes but does not affect test execution. Learn more

Build reactor — dependencies compiled but only changed modules were tested (2 modules, 17.3s total)

Total reactor time: 17.3s

Module	Duration	Status
Camel :: Docs	11.3s	SUCCESS
Camel :: Vert.x :: Common	6.0s	SUCCESS

Top 20 slowest modules:

• Camel :: Docs (11.3s)
• Camel :: Vert.x :: Common (6.0s)

---

⚙️ View full build and test results

[davsclaus]

TL;DR

Comment — a correct, focused fix: VertxHelper now applies any standalone TrustManager set on TrustManagersParameters, not only TrustAllTrustManager.INSTANCE. That gives it the same precedence as TrustManagersParameters.createTrustManagers() in core (a standalone TrustManager wins over the keystore). Ready to merge; the points below are follow-ups.

Blockers

• None

Other findings: 1 non-blocking, 2 suggestions — see below.

Non-blocking

1. Backport labels and the LTS upgrade-guide entries. CAMEL-25964 has fixVersions 4.24.0, 4.22.3 and 4.18.6, and camel-4.22.x and camel-4.18.x have the same == TrustAllTrustManager.INSTANCE check. The PR has no port/camel-4.22.x / port/camel-4.18.x labels, and the upgrade-guide note is only in camel-4x-upgrade-guide-4_24.adoc. Per the backport upgrade-guide policy in .oss-ai-helper-rules/project-guidelines.md, the same note belongs in the "Upgrading from 4.22.2 to 4.22.3" section of camel-4x-upgrade-guide-4_22.adoc and the "Upgrading from 4.18.5 to 4.18.6" section of camel-4x-upgrade-guide-4_18.adoc on main.

Suggestions (inline)

2. VertxHelperTest: the standalone and trust-all tests only check that some trust options are set; they can check that the configured TrustManager is the one Vert.x will use.
3. Upgrade guide: one more sentence for the case where both a TrustManager and a keystore are set.

A note for other reviewers: VertxHelper.java shows as rewritten because the file had CRLF line endings on main and is LF now; with whitespace ignored the change is 10 added and 9 removed lines.

This review covers the project's rules and conventions; it does not replace specialized review tools or static analysis.

Claude Code on behalf of @davsclaus

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[oscerd]

Pushed one more commit for the review: "CAMEL-25964: Address review feedback - assert the TrustManager that Vert.x applies, and document the TrustManager-over-keystore case".

• VertxHelperTest: both tests now assert that the TrustManager the Vert.x trust options wrap is the configured one (the custom manager, and TrustAllTrustManager.INSTANCE), as suggested inline.
• Upgrade guide: a second paragraph for the case where both a TrustManager and a keystore are set on TrustManagersParameters — the TrustManager is now used, as in the other components that use SSLContextParameters.
• Backports (non-blocking point 1): the camel-4.22.x and camel-4.18.x ports follow once this is merged; the matching notes in the 4.22.2 → 4.22.3 and 4.18.5 → 4.18.6 sections of the guides on main come with them, so that main does not announce the fix for a release before the port is in.

VertxHelperTest passes locally (JDK 21). Since the two approvals were given on the previous head, I have re-requested the review.

Claude Code on behalf of oscerd

[davsclaus]

Thanks Andrea, the new commit addresses the review:

• VertxHelperTest now checks that the configured TrustManager is the one Vert.x uses, for the custom manager and for TrustAllTrustManager.INSTANCE. In Vert.x 5.2.1, TrustOptions.wrap(tm) builds a TrustManagerFactoryWrapper whose getTrustManagers() returns the wrapped manager, so the assertions test the fix (they fail on main, where a custom manager is not applied).
• The upgrade guide covers the case where both a TrustManager and a keystore are set. This matches the code: setupSSLOptions checks getTrustManager() first.

On the backports: doing the 4.22.3 / 4.18.6 upgrade-guide notes on main together with the ports is fine (the policy allows a follow-up doc-sync). If the port/camel-4.22.x and port/camel-4.18.x labels are added before merging, the backport bot opens the port PRs on merge.

LGTM once CI is green.

Claude Code on behalf of @davsclaus. This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[davsclaus]

/port

[gnodet]

🔄 Backport Bot

Conflicts (🤖 agent dispatched to resolve):

• ⚠️ camel-4.22.x — Cherry-pick conflict in: docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_24.adoc
• ⚠️ camel-4.18.x — Cherry-pick conflict in: components/camel-vertx/camel-vertx-common/src/main/java/org/apache/camel/component/vertx/common/VertxHelper.java, docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_24.adoc

ℹ️ If you push additional commits after /port, use /port again to update the port PRs.

[gnodet]

✅ Backport to camel-4.22.x created: #28345

[gnodet]

✅ Backport to camel-4.18.x created: #28346