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

   _Claude Code on behalf of Federico Mariani (@Croway)_
   
   Resolves [CAMEL-23999](https://issues.apache.org/jira/browse/CAMEL-23999) 
and [CAMEL-24000](https://issues.apache.org/jira/browse/CAMEL-24000).
   
   Modernization of `core/camel-spring-boot` following a review against Spring 
Boot 4.1.x best practices, plus one build regression fix found along the way.
   
   ## CAMEL-23999 — restore `spring-configuration-metadata.json` (regression)
   
   The maven-compiler-plugin 3.15.0 upgrade (#1648) silently stopped running 
annotation processors discovered on the compile classpath (behaviour change in 
maven-compiler-plugin 3.13+). As a result the core and **all starter jars** 
were built without `META-INF/spring-configuration-metadata.json` — breaking IDE 
completion for every `camel.*` property — and the generated 
`src/main/docs/*.json` files could no longer be regenerated. Fixed with 
`<proc>full</proc>` in the root POM; verified the metadata is back in both the 
core jar and a starter jar.
   
   ## CAMEL-24000 — Spring Boot 4 idiom alignment
   
   - **`MainListener` beans notified exactly once with 
`camel.main.run-controller=true`.** They previously received 
`beforeStart`/`afterStart` (and the stop callbacks) twice: once from the 
controller created by `CamelAutoConfiguration` (the complete callback stream 
added in CAMEL-21359) and once more from the run controller's internal `Main`. 
The run controller no longer registers the listener beans. A new test 
(`CamelMainListenerRunControllerTest`) asserts exactly-once delivery for all 
seven callbacks — it was written first and demonstrated the duplication 
(`beforeStart=2, afterStart=2`) before the fix.
   - **Dead code removed**: `HierarchicalCondition` and 
`CompositeConversionService` (referenced by nothing), 
`ClusteredRouteControllerConfiguration.clusterServiceRef` (no accessors, never 
bindable), unused import in `CamelDevConsoleAutoConfiguration`.
   - **No more mutation of shared `@ConfigurationProperties` beans**: the 
trace, error registry and security policy auto-configurations applied dev/prod 
profile defaults by mutating the injected singleton, so other beans reading the 
same properties observed altered values. Effective values are now computed 
locally.
   - **`@ConditionalOnBooleanProperty`** (Spring Boot 3.4+) replaces 
`@ConditionalOnProperty(name = "enabled")` on the supervising and clustered 
route controller auto-configurations; the redundant in-method `isEnabled()` 
re-check and null `@Bean` return are gone.
   - **Vault auto-configurations consolidated**: the eight hand-written 
per-field copy chains are replaced by `BeanUtils.copyProperties` (all 
properties mirror the Camel core vault configurations by name and type), 
guarded by a new reflection test that fails when Camel core gains a vault 
option the starter does not expose. The test immediately found real drift: 
`camel.vault.ibm.refresh-enabled` and `camel.vault.ibm.secrets` existed in 
Camel core but could not be configured from Spring Boot — both added and 
`spring-boot.json` regenerated.
   - **Duration properties bound as `java.time.Duration`** with 
`@DurationUnit(MILLIS)`: supervising route controller `initial-delay` / 
`back-off-delay` / `back-off-max-delay` / `back-off-max-elapsed-time` and 
startup condition `interval` / `timeout`. Plain numeric values keep meaning 
milliseconds (existing tests binding plain numbers pass unchanged); readable 
values like `5s` now work too.
   
   ## Compatibility notes
   
   - The getters of the two converted properties classes change type 
(`long`/`int` → `Duration`); these classes are starter-internal but technically 
public API.
   - The clustered route controller `initial-delay` deliberately **keeps** its 
`String` type + `TimePatternConverter`: it accepts Camel time patterns (e.g. 
`10 seconds`) that `Duration` binding does not support, so converting it would 
break existing configurations.
   - Null `@Bean` returns in the trace/errorregistry/threadpool/routetemplate 
auto-configurations were kept: their conditions depend on the runtime Camel 
profile or on "any property under the prefix" semantics, which cannot be 
expressed declaratively.
   
   ## Testing
   
   - `mvn verify` on `core/camel-spring-boot` passes (full suite + ITs).
   - New tests: `CamelMainListenerRunControllerTest` (exactly-once listener 
callbacks), `VaultConfigurationPropertiesMappingTest` (vault option drift 
guard).
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


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