CAMEL-23999/CAMEL-24000: camel-spring-boot - Spring Boot 4 idiom alignment and configuration metadata regression fix

[Croway]

Claude Code on behalf of Federico Mariani (@Croway)

Resolves CAMEL-23999 and 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

Review follow-ups

• Math.toIntExact() instead of (int) cast when converting the startup condition interval/timeout to millis, so overflow fails fast (review feedback).
• Upgrade guide entry for the Duration property type changes: CAMEL-24000: camel-spring-boot - upgrade guide entry for Duration configuration properties camel#24593.

[davsclaus]

Claude Code on behalf of Claus Ibsen (@davsclaus)

Nice work, Federico — this is a well-structured PR with clear atomic commits and good test coverage. The git history confirms all changes are consistent with prior intent (none revert intentional decisions), and the MainListener exactly-once fix addresses a genuine bug from CAMEL-21359.

Confirmed findings

1. Narrowing cast (int) Duration.toMillis() — potential overflow (Low)

In CamelAutoConfiguration.java, Duration.toMillis() returns long; casting to int silently wraps for values > ~24.8 days. The defaults (500ms, 20s) make this safe in practice, but Math.toIntExact() would turn a misconfiguration into a clear ArithmeticException instead of silent wraparound.

2. Missing upgrade guide entry for property type changes (Medium)

The getter/setter types on SupervisingRouteControllerConfiguration (long → Duration) and CamelStartupConditionConfigurationProperties (int → Duration) are public API changes. @DurationUnit(MILLIS) ensures backward compatibility for plain numeric values in application.properties, but code calling e.g. config.getBackOffDelay() and expecting a long will fail to compile. An upgrade guide entry documenting the type changes would be appropriate.

Observations (non-blocking)

• @ConditionalOnBooleanProperty semantic tightening: the old @ConditionalOnProperty(name = "enabled") matched any value except "false"; the new annotation only matches "true" (case-insensitive). Correct behavior for a boolean flag, but technically a subtle change.
• BeanUtils.copyProperties for vault configs: clean simplification, and the new VaultConfigurationPropertiesMappingTest is an excellent drift guard.
• Dead code removals (CompositeConversionService, HierarchicalCondition, clusterServiceRef): verified — no references anywhere in the repo.
• IBM vault drift fix (refreshEnabled, secrets): confirmed genuine missing configuration.

This review does not replace specialized tools like CodeRabbit, Sourcery, or SonarCloud.

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

[davsclaus]

Minor: Duration.toMillis() returns long; the (int) cast silently wraps for large values. Consider using Math.toIntExact() to fail fast on misconfiguration instead of silent overflow:

Suggested change

	scs.setInterval((int) config.getInterval().toMillis());
	scs.setTimeout((int) config.getTimeout().toMillis());
	scs.setInterval(Math.toIntExact(config.getInterval().toMillis()));
	scs.setTimeout(Math.toIntExact(config.getTimeout().toMillis()));

[Croway]

Applied in 25b33d8 — switched to Math.toIntExact() for both interval and timeout. Thanks!

Claude Code on behalf of Federico Mariani.

[Croway]

Both review findings addressed:

1. Overflow on (int) Duration.toMillis() — fixed in 25b33d8 using Math.toIntExact(), so a misconfigured interval/timeout now fails fast with ArithmeticException instead of silently wrapping.
2. Upgrade guide entry — the 4.x upgrade guides live in the main repo, so this is covered by CAMEL-24000: camel-spring-boot - upgrade guide entry for Duration configuration properties camel#24593 (documents the Duration type changes, the plain-numbers-stay-millis compatibility, and why camel.clustered.controller.initial-delay keeps its String type).

Claude Code on behalf of Federico Mariani.