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

   Fixes [CAMEL-24501](https://issues.apache.org/jira/browse/CAMEL-24501).
   
   `SpringBootAutoConfigurationMojo` generates two pieces of binding code into 
every starter that discard
   configuration without reporting it, so an option that never took effect is 
indistinguishable from one that
   did. Both are addressed here; the third item on the ticket is deferred and 
explained below.
   
   ## 1. Generated converters no longer turn an unresolvable value into `null`
   
   An option of a complex (object) type is configured with a reference to a 
bean:
   
   ```properties
   camel.component.http.ssl-context-parameters = #bean:mySslContextParameters
   ```
   
   The generated `convert()` body returned `null` for any value that did not 
start with `#`, and for a value
   naming a bean that does not exist, so a typo in the bean id produced a 
component with the option unset. It
   also returned `null` for a target type its `switch` did not list, which 
happens when the bound type is a
   subtype of a registered pair.
   
   The body now delegates to a new 
`org.apache.camel.spring.boot.util.BeanReferenceHelper`, which
   
   - resolves `#bean:myBean`, `#myBean`, a plain `myBean`, `#autowired` and 
`#type:com.foo.MyType`;
   - throws `IllegalArgumentException` naming the value, the target type and 
the configuration prefix when the
     value cannot be resolved to a bean of that type.
   
   The per-type `switch` is gone, so the generated converters shrink to a 
single delegating line and the whole
   "not in the switch" branch disappears.
   
   ## 2. Generated customizers no longer drop an option that cannot be set
   
   `createComponentBody` / `createDataFormatBody` / `createLanguageBody` emitted
   `CamelPropertiesHelper.copyProperties`, which binds with 
`failIfNotSet=false`, while the same mojo emits
   `failIfNotSet=true` for the `camel.rest.*` path. They now call a new
   `CamelPropertiesHelper.copyConfigurationProperties`, which
   
   - removes `enabled` and `customizer` before binding — they belong to the 
auto-configuration layer, not to the
     Camel target, and were being offered to it on every startup;
   - fails with `IllegalArgumentException` when an option **the application 
configured itself** cannot be set;
   - logs at `DEBUG` when an option that only carries its catalog default 
cannot be set.
   
   Whether an option was configured by the application is decided with Spring's
   `ConfigurationPropertySources`, so relaxed binding and environment variables 
are handled.
   
   ### Why not blanket `failIfNotSet=true`
   
   That was the first implementation, and it does not survive contact with the 
existing generated code. The
   configuration classes materialise every catalog default as a field 
initializer (item 2 on the ticket), so the
   customizer copies defaults for options that were never bindable. The 
clearest case is `camel-core-starter`:
   
   ```
   Cannot configure option [trim] with value [true] as the bean class
   [org.apache.camel.language.simple.SimpleLanguage] has no suitable setter 
method
   ```
   
   `trim`, `pretty`, `trimResult` and `nested` are options of the expression 
model, not of `SimpleLanguage`, and
   they carry catalog defaults, so `failIfNotSet=true` would abort startup for 
every application that has
   `camel-core-starter` on the classpath. Failing only on options the 
application actually set keeps the fix
   narrow and still closes the reported hole.
   
   ## Behaviour change and how to opt back
   
   An application that configured an option which never took effect now fails 
at startup, with a message naming
   the option. The remedy is to correct or remove it. To keep starting while 
doing so:
   
   ```properties
   camel.springboot.lenient-configuration-binding = true
   ```
   
   Such an option is then logged at `WARN` with its name, instead of being 
dropped silently as before. The
   legacy `CamelPropertiesHelper.copyProperties` / `setCamelProperties(..., 
failIfNotSet=false)` path, which is
   public API and no longer used by generated code, also logs at `WARN` now 
instead of staying silent.
   
   An upgrade-guide entry for 
`docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc` in
   `apache/camel` has been written and will be raised separately.
   
   ## Deferred
   
   Item 2 of the ticket — catalog defaults emitted as literal field 
initializers, so the customizer copies a
   default over a value set programmatically on a user-supplied component bean 
— is **not** fixed here. Dropping
   the initializers is not a local change:
   
   - the generated getters return the defaults today, and those getters are 
effectively public API;
   - `spring-configuration-metadata.json` derives `defaultValue` from the field 
initializers, so IDE completion
     and the generated `.adoc` documentation pages (which the readme mojo 
builds from that metadata) would both
     lose every default;
   - the alternative — having the customizer skip a value equal to the catalog 
default — makes it impossible to
     set an option back to its default explicitly.
   
   It needs its own change with the metadata and docs generation adjusted at 
the same time, and it is the
   prerequisite for turning the strictness above into blanket 
`failIfNotSet=true`. The ticket is left open for it.
   
   Restricting the generated converters to `camel.*` property sources is also 
not done. `ConditionalGenericConverter.matches`
   only receives the source and target `TypeDescriptor`, never the property 
name, so the only way to make it
   selective is to mark every complex-typed field on the ~425 generated 
configuration classes with an annotation
   the converter tests for. Worth doing, but it belongs with a change that 
touches those classes anyway.
   
   ## Tests
   
   - `SpringBootAutoConfigurationMojoTest` (new, 4 tests) — asserts the 
generated converter and customizer
     bodies.
   - `BeanReferenceHelperTest` (new, 13 tests) — every supported syntax plus 
the failure cases.
   - `CamelPropertiesHelperTest` (3 new tests) — `enabled`/`customizer` are not 
offered to the target, a
     configured option that cannot be set fails, a catalog default that cannot 
be set does not.
   - `CamelPropertiesHelperLenientBindingTest` (new) — the opt-out.
   - `HttpComponentBeanReferenceBindingTest` (new, 4 tests) — end-to-end 
through the Spring Boot binder on a real
     starter.
   
   Run green: the generator plugin, `core/camel-spring-boot` (full suite), 
`camel-http-starter`,
   `camel-netty-http-starter` and `camel-jackson-starter`.
   
   _Claude Code (Opus 5) 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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to