oscerd opened a new pull request, #26166:
URL: https://github.com/apache/camel/pull/26166
## What
The vault components already detect a rotated secret and trigger a context
reload, but the reload stopped short of the components that hold the
authenticated connection. This adds the missing half.
`DefaultContextReloadStrategy.onReload()` did two things: restart the
`PropertiesSource`s, then `RouteController.reloadAllRoutes()`. Routes and
endpoints are rebuilt, but components and registry beans are not, which
`context-reload.adoc` stated outright ("General services in CamelContext and
java beans or Camel Processor is not updated"). So after a rotation the reload
looked successful while the connections stayed stale.
Two complementary changes:
### 1. Re-apply placeholder based options (`reloadComponentProperties`)
`MainPropertiesReload` already knows how to re-apply `camel.component.*`
onto components, but it is registered as a `PropertiesReload` service and was
only invoked from the file-watch strategies. `DefaultContextReloadStrategy`
never looked it up. A component option such as
`camel.component.kafka.saslJaasConfig={{aws:broker-credentials}}` therefore
kept its bootstrap-resolved value forever, and because the raw placeholder is
not retained on the component, the component could not have re-resolved it on
its own.
The reload now hands `PropertiesReload` the `camel.` options whose value is
a placeholder, which are the only ones whose resolved value can change while
the raw configuration stays the same.
### 2. New `SecretRotationAware` SPI
Re-applying the options refreshes the component fields, but anything holding
a live authenticated resource built from those fields still has to rebuild it:
a pooled JMS `ConnectionFactory`, a Hikari `DataSource`, a shared
`HttpClientConnectionManager`. Components and registry beans can now implement
`org.apache.camel.spi.SecretRotationAware` to be told. The callback runs after
the options are re-applied and before the routes restart, so the resource is
already authenticated by the time the routes come back up. A callback that
throws is logged and skipped, so one component cannot break the reload for the
others.
## Scope
Core SPI and wiring only. The adoptions where the SPI earns its place, the
registry-owned pools that Camel references but does not create, are sub-tasks
CAMEL-24637 (jms), CAMEL-24638 (jdbc/sql) and CAMEL-24639 (http).
camel-kafka was originally going to be the reference implementation, but it
caches no live client: its producers and consumers are rebuilt by the route
reload, and its component-level `saslJaasConfig` / `sslKeystorePassword` are
refreshed by change 1. A `KafkaComponent.onSecretRotation()` would have been
dead code, so it was dropped rather than added for the sake of having an
in-tree example.
Deliberate boundary: the file-watch path (`RouteWatcherReloadStrategy`)
already calls `PropertiesReload`, but does not notify `SecretRotationAware`. It
sits in a different hierarchy (`ResourceReloadStrategySupport`), and this issue
is about vault-triggered rotation, so sharing the notification is left as a
follow-up rather than refactored here.
## Testing
- `MainContextReloadSecretRotationTest` (camel-main) is the end-to-end
proof: a `PropertiesFunction` standing in for a vault,
`camel.component.dummy.component-value={{vault:password}}`, rotate the secret,
trigger the reload, then assert the component option holds the new secret and
the `SecretRotationAware` bean was notified. **This test was verified to fail
without the fix** (`expected: "password-2" but was: "password-1"`).
- `CamelContextSecretRotationAwareTest` (camel-core) covers that the
notification happens, happens on every reload, is isolated from a listener that
throws, and runs before the routes are reloaded.
- `ContextReloadComponentPropertiesTest` (camel-core) covers the filtering:
only `camel.` options whose value is a placeholder are passed through, and they
arrive as an `OrderedLocationProperties`, which is what `MainPropertiesReload`
requires.
- The existing reload tests pass unchanged (8 tests across
`CamelContextReloadStrategy*Test` and `RouteWatcherReloadStrategy*Test`).
## Compatibility
The SPI is additive and opt-in: a component that does not implement it
behaves exactly as before, and no public API signature changed.
Change 1 is a behaviour change. A component configured with a placeholder
based option is now re-created on a context reload, exactly as it already is
when that option changes in a watched properties file. It is documented in the
4.23 upgrade guide.
_Claude Code on behalf of oscerd_
🤖 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]
