CAMEL-24317: camel-aws2-eventbridge - throw when pojoRequest=true and the body is the wrong type

[oscerd]

Child of CAMEL-24261 (completing CAMEL-23462 across the AWS2 producers).

Problem

With pojoRequest=true, EventbridgeProducer.putRule only acted when the body
was a PutRuleRequest; any other body fell through the instanceof with no
else, so no AWS call was made, no response was set, and the original body was
returned with no error. (The other Eventbridge operations already build their
request from headers and don't have a pojo branch.)

Fix

} else {
    throw new IllegalArgumentException(
            "putRule operation requires PutRuleRequest in POJO mode");
}

Test

camel-aws2-eventbridge has no producer route/mock harness, so this is covered
by a new Mockito unit test (EventbridgeProducerPojoRequestTest) that mocks the
endpoint + client, sends a wrong-typed body with pojoRequest=true, and asserts
the IllegalArgumentException. Verified to fail (silent no-op) before the fix.
Region-free — no localstack or real AWS.

Docs / backport

The shared 4.22 upgrade-guide entry was added with CAMEL-24263. Main only, matching
the CAMEL-23462 precedent (behaviour change, shipped in a minor, not backported).

---

Claude Code on behalf of oscerd

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

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-aws/camel-aws2-eventbridge

---

🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 9 all tested

Maveniverse Scalpel detected 38 affected modules (current approach: 9).

⚠️ Modules only in Scalpel (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

Skip-tests mode would test 9 modules (1 direct + 8 downstream), skip tests for 29 (generated code, meta-modules)

Modules Scalpel would test (9)

• camel-aws2-eventbridge
• camel-jbang-mcp
• camel-jbang-plugin-mcp
• camel-jbang-plugin-route-parser
• camel-jbang-plugin-tui
• camel-jbang-plugin-validate
• camel-launcher-container
• camel-yaml-dsl-validator
• camel-yaml-dsl-validator-maven-plugin

Modules with tests skipped (29)

• apache-camel
• camel-allcomponents
• camel-catalog
• camel-catalog-console
• camel-catalog-lucene
• camel-catalog-maven
• camel-catalog-suggest
• camel-componentdsl
• camel-csimple-maven-plugin
• camel-endpointdsl
• camel-endpointdsl-support
• camel-itest
• camel-jbang-core
• camel-jbang-it
• camel-jbang-main
• camel-jbang-plugin-edit
• camel-jbang-plugin-generate
• camel-jbang-plugin-kubernetes
• camel-jbang-plugin-test
• camel-kamelet-main
• camel-launcher
• camel-report-maven-plugin
• camel-route-parser
• camel-yaml-dsl
• camel-yaml-dsl-deserializers
• camel-yaml-dsl-maven-plugin
• coverage
• docs
• dummy-component

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

All tested modules (38 modules)

• Camel :: AWS2 Eventbridge
• Camel :: All Components Sync point
• Camel :: Assembly
• Camel :: Catalog :: CSimple Maven Plugin (deprecated)
• Camel :: Catalog :: Camel Catalog
• Camel :: Catalog :: Camel Report Maven Plugin
• Camel :: Catalog :: Camel Route Parser
• Camel :: Catalog :: Console
• Camel :: Catalog :: Dummy Component
• Camel :: Catalog :: Lucene (deprecated)
• Camel :: Catalog :: Maven
• Camel :: Catalog :: Suggest
• Camel :: Component DSL
• Camel :: Coverage
• Camel :: Docs
• Camel :: Endpoint DSL
• Camel :: Endpoint DSL :: Support
• Camel :: Integration Tests
• Camel :: JBang :: Core
• Camel :: JBang :: Integration tests
• Camel :: JBang :: MCP
• Camel :: JBang :: Main
• Camel :: JBang :: Plugin :: Edit
• Camel :: JBang :: Plugin :: Generate
• Camel :: JBang :: Plugin :: Kubernetes
• Camel :: JBang :: Plugin :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: TUI
• Camel :: JBang :: Plugin :: Testing
• Camel :: JBang :: Plugin :: Validate
• Camel :: Kamelet Main
• Camel :: Launcher
• Camel :: Launcher :: Container
• Camel :: YAML DSL
• Camel :: YAML DSL :: Deserializers
• Camel :: YAML DSL :: Maven Plugins
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[gnodet]

The production fix is correct — putRule was missing the else branch to throw when pojoRequest=true and the body is not a PutRuleRequest, matching the CAMEL-24261 series pattern. The test logic is sound and compiles/passes correctly (assertj-core is already available on main).

Minor observation (not blocking):

putRule is the only operation in EventbridgeProducer that was not migrated to use the executeOperation helper (all other operations — putTargets, removeTargets, deleteRule, enableRule, disableRule, listRules, describeRule, listTargetsByRule, listRuleNamesByTarget, putEvent — already use it). The error message format here ("putRule operation requires PutRuleRequest in POJO mode") differs from executeOperation's more debuggable format ("Expected body of type %s but was %s") which includes both the expected and actual type names. Consider either migrating putRule to use executeOperation or matching its error message format for consistency and debuggability.

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

Claude Code on behalf of Guillaume Nodet

[gnodet]

Re-review after new commit: the second commit correctly addresses the previous review feedback by aligning the putRule error message format with executeOperation's pattern. The else-branch now uses the same String.format("Expected body of type %s but was %s", ...) with the ObjectHelper.isNotEmpty null-guard, and the test assertion was updated to match. CI passes on both JDK 17 and 25.

Claude Code on behalf of Guillaume Nodet