Croway commented on PR #2078:
URL:
https://github.com/apache/camel-spring-boot/pull/2078#issuecomment-6737716095
@smongiar thanks, agreed on keeping this as a draft.
One thing to add to the new ticket: #1951 has already been released, since
`camel-spring-boot-4.23.0` contains it. So this regression affects a released
version, not only this backport.
**main: A.** It's close to what CAMEL-24501 originally proposed ("have the
customizer skip values equal to the catalog default"). Some notes:
- Map/List: I don't think this is really an open point. The only
object-valued initializer in the generated configuration classes is
`serverConfig = new HashMap<>()` in the Jolokia starter, and two empty
`HashMap`s compare equal. Collections without an initializer are `null` on a
fresh instance, so a Map or List set in Java always differs and gets copied.
- Fallback: the generated classes always have a no-arg constructor, so this
should never trigger. I'd fall back to copying everything, as
`boundProperties()` already does when it cannot tell what was bound, rather
than to bound-only.
- Compute the fresh-instance values once per configuration class.
- Known gap: a Java assignment equal to the catalog default is still not
copied. For example, `setSkipRequestHeaders(false)` won't reach a user
`HttpComponent` bean that has `true`. That's acceptable to me, but please
document it. Also update the paragraph #1951 added to
`starter-configuration.adoc`, which only covers external configuration.
- Tests: the `HttpComponentConfiguration` scenario from my comment, the
ai-tool hints staying unset, and a bound value equal to the catalog default
still being copied onto a user bean.
Agreed that B is out for 4.22.x. On main it would also need the helper to go
back to copying every non-null value, so A is the smaller change.
**4.22.x: C, and close this PR.** On a patch branch, #1951 changes every
starter: any option the application doesn't configure moves from the catalog
default to the component's own Java default wherever the two differ. The
`false` defaults come from Camel's catalog tooling, where
`BaseOptionModel.resolveDefaultValue()` maps any default other than `"true"` to
`false` for `java.lang.Boolean`. Only 8 of the 607 `java.lang.Boolean` options
in the 4.22.2 component catalogs have no default, so many nullable Booleans
would go from `false` to `null`. That's the right model on main, but too broad
to audit for a patch release. C changes only the ai-tool starter.
Please open one CAMEL ticket for this, linked to CAMEL-24501, with
fixVersions 4.24.0 (A on main) and 4.22.3 (C on 4.22.x), and I'll review.
_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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
