You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by "Croway (via GitHub)" <gi...@apache.org> on 2026/09/09 10:46:20 UTC

[PR] [backport camel-spring-boot-4.22.x] CAMEL-24501: Report starter configuration options that cannot be bound [camel-spring-boot]

Croway opened a new pull request, #1960:
URL: https://github.com/apache/camel-spring-boot/pull/1960

   Cherry-pick of #1935 onto `camel-spring-boot-4.22.x`.
   
   **Original PR:** #1935 — CAMEL-24501: Report starter configuration options that cannot be bound
   **JIRA:** [CAMEL-24501](https://issues.apache.org/jira/browse/CAMEL-24501)
   
   ### What it fixes
   
   `SpringBootAutoConfigurationMojo` generates two pieces of binding code into every starter, and both used to discard configuration silently instead of reporting it — so an option that never took effect looked identical to one that did.
   
   First, generated converters for complex (object) type options bound via a bean reference (e.g. `camel.component.http.ssl-context-parameters = #bean:mySslCtx`) used to return `null` whenever the reference couldn't be resolved — a typo'd bean id, or a target type the converter didn't know about. The generated `convert()` body now delegates to a new `BeanReferenceHelper`, which resolves `#bean:myBean` / `#myBean` / plain `myBean` / `#autowired` / `#type:fqn`, and throws `IllegalArgumentException` naming the value, target type and configuration prefix when it can't resolve. This strict behaviour is scoped to classes that are Camel's own (under `org.apache.camel`, or `@ConfigurationProperties` with a `camel.` prefix) — a third-party class such as `javax.net.ssl.HostnameVerifier` that happens to share a type with a starter keeps its pre-existing lenient behaviour, so an unrelated application property can't be made to fail binding by a starter on the classpath.
   
   Second, generated customizers no longer drop an option that can't be set on the target bean. They now call a new `CamelPropertiesHelper.copyConfigurationProperties`, which strips `enabled`/`customizer` before binding, fails with `IllegalArgumentException` when an option the application explicitly configured can't be set, and only logs at DEBUG when the option that can't be set merely carries its catalog default (not a hard failure — catalog defaults are currently materialized as field initializers regardless of whether the application configured them, which is item 2 of the ticket and a separate, still-open follow-up, deliberately **not** included in this backport).
   
   ### Behavior change and opt-out
   
   An application that configures an option which can never actually take effect now fails at startup, naming the option, instead of silently starting up with that option dropped. `camel.springboot.lenient-configuration-binding=true` restores the previous tolerant behaviour, logging at WARN instead of failing.
   
   ### Verification on this branch
   
   - Cherry-picked all 3 commits (`b689587a76a`, `2e48974f6bf`, `e59029e0182`) in order with `git cherry-pick -x`. This did **not** apply cleanly against the current `camel-spring-boot-4.22.x` tip:
     - The "Regen" commit conflicted on 8 generated files belonging to starters that don't exist on this branch at all (`camel-hivemq-starter`, `camel-python3-starter`, `camel-quickjs-starter`, `camel-rest-postman-starter`, `camel-toon-starter`, `camel-ubl-starter` — added to `main` after this branch diverged). Resolved by removing those files, matching this branch's (correct) deletion of them.
     - The follow-up commit conflicted in `core/camel-spring-boot/src/main/resources/META-INF/additional-spring-configuration-metadata.json`: the new `camel.springboot.lenient-configuration-binding` entry was inserted next to a `camel.vault.ignore-resolution-failures` entry that exists on `main` (from an unrelated, unbackported change) but not on this branch. Resolved by keeping only the `lenient-configuration-binding` entry that belongs to this ticket.
   - `core/camel-spring-boot` test suite: `mvn verify` — 164 unit tests + 2 integration tests, all passed, including the new `BeanReferenceHelperTest` (22 tests) and `CamelPropertiesHelperLenientBindingTest`.
   - `tooling/camel-spring-boot-generator-maven-plugin` test suite: `mvn verify` — 9 tests, all passed, including the new `SpringBootAutoConfigurationMojoTest`.
   - Spot-check: `camel-http-starter` builds cleanly against the regenerated code, and its new `HttpComponentBeanReferenceBindingTest` (6 tests) passes, exercising the fix end-to-end (unresolvable bean reference on a Camel property fails with `IllegalArgumentException`; an unrelated third-party property type keeps its lenient behaviour).
   - Local build used a temporary repoint of the SNAPSHOT parent/`camel-version`/BOM entries to the released `4.22.0` (this branch's SNAPSHOT parent isn't resolvable from a fresh checkout); those edits were reverted before pushing — the pushed branch contains only the 3 cherry-picked commits' real changes.
   
   _Claude Code on behalf of Federico Mariani_
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [backport camel-spring-boot-4.22.x] CAMEL-24501: Report starter configuration options that cannot be bound [camel-spring-boot]

Posted by "Croway (via GitHub)" <gi...@apache.org>.
Croway merged PR #1960:
URL: https://github.com/apache/camel-spring-boot/pull/1960


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org