CAMEL-23295: Fix resource leak and improve error handling in camel-splunk-hec producer

[oscerd]

Summary

Claude Code on behalf of Andrea Cosentino

• Add warning log when skipTlsVerify is enabled to alert operators that TLS verification is disabled
• Replace generic RuntimeException with RuntimeCamelException for proper Camel error handling
• Log error response body at DEBUG level for easier debugging of Splunk HEC failures
• Consume response entity on success path to prevent potential connection leaks
• Add unit tests for error handling behavior (2 tests)

Fixes: https://issues.apache.org/jira/browse/CAMEL-23295

Test plan

• All existing tests pass (30 tests, 0 failures)
• New SplunkHECProducerTest verifies RuntimeCamelException is thrown on 400 and 503 responses
• @AfterEach properly closes CamelContext to prevent resource leaks in tests

🤖 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]

Review

Claude Code on behalf of Guillaume Nodet

Overall a solid, well-scoped bug fix. A couple of items worth addressing:

Issues

1. (Medium) Missing CamelContext cleanup in test
SplunkHECProducerTest.java — @BeforeEach creates and starts a DefaultCamelContext but there is no @AfterEach to stop/close it. This leaks resources across test runs. Please add:

@AfterEach
void tearDown() {
    camelContext.close();
}

2. (Low) Third test is redundant
testExceptionTypeIsRuntimeCamelExceptionNotRuntimeException catches Exception.class and asserts the class is exactly RuntimeCamelException.class. The other two tests already use assertThrows(RuntimeCamelException.class, ...) — if the type were wrong, those would fail first. Consider removing this test to keep the test class focused.

Positives

• RuntimeException → RuntimeCamelException follows Camel conventions
• EntityUtils.consume() on the success path properly prevents connection pool leaks
• TLS verification warning is appropriate
• Good test coverage for the error paths

This review covers project conventions, correctness, and test coverage. It does not replace specialized tools like SonarCloud or CodeRabbit.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-splunk-hec

All tested modules (7 modules)

• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: Splunk HEC
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[oscerd]

Claude Code on behalf of Andrea Cosentino

@gnodet Thank you for the review! Both items addressed in 3c5e848:

1. CamelContext cleanup — Added @AfterEach with camelContext.close() to prevent resource leaks across test runs.
2. Redundant test — Removed testExceptionTypeIsRuntimeCamelExceptionNotRuntimeException since the other two tests already verify the exception type via assertThrows(RuntimeCamelException.class, ...).