Technical article
External database support: switch a route's target database from configuration, not XML
MysqlRouteSrv v1.0.0 shows how the LightESB externaldb component moves database target selection out of Camel route XML and into service configuration. Datasources register dynamically as extdb-<id>-datasource beans, routes reference them through one placeholder, and switching the target database becomes a properties edit plus a reload — the SQL route never changes.
Hardcoded datasources do not survive environments
Database endpoints and credentials vary by environment and by route. Hardcoding datasource names in XML routes turns every environment move into a route edit — high change cost, high regression risk.
externaldb moves target selection to the config layer: route SQL stays stable, datasources are registered dynamically in the Camel Registry, and the target database is switched by properties instead of route rewrites. MysqlRouteSrv v1.0.0 uses this mechanism to verify MySQL connectivity and a basic CRUD flow on a fixed schedule.
The mechanism in four parts
Enablement and priority
system.components=externaldb turns the component on in common.config.properties. The extdb.* datasource model lives in service.config.properties, and service-level settings override common defaults.
Dynamic registry beans
Once externaldb is loaded, the Camel Registry holds extdb-<id>-datasource (for example extdb-primary-datasource) plus extdb-default-datasource, extdb.config, and extdb.route.targets.
One placeholder, stable SQL
SQL endpoints point at #bean:extdb-{{mysqlroute.target.datasource}}-datasource. The same reference pattern is reused for select, insert, query, and delete against testexdb, so redirection is pure configuration.
Timer-driven verification
The service runs with HTTP.Listener=false. A timer route fires every 60 seconds and runs the health check against the selected datasource, so the validation evidence lives in the route log.
Real configuration, real route
The service-level datasource model, from service.config.properties:
extdb.enabled=true
extdb.default=primary
extdb.ids=primary
extdb.primary.type=mysql
extdb.primary.url=jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
extdb.primary.driver=com.mysql.cj.jdbc.Driver
extdb.primary.username=root
extdb.primary.password=nghxni
extdb.primary.maxPoolSize=10
mysqlroute.target.datasource=primaryThe timer route wires the SQL component through the placeholder, from mysql-healthcheck-route.xml:
<from uri="timer://mysql-healthcheck?fixedRate=true&period=60000"/>
<setHeader name="db.target">
<simple>{{mysqlroute.target.datasource}}</simple>
</setHeader>
<to uri="sql:select 1 as db_ok?dataSource=#bean:extdb-{{mysqlroute.target.datasource}}-datasource&outputType=SelectOne"/>Verification is log-based: logs/mysql-healthcheck-route.log should show the health check starting with target=primary, select 1 returning result=1, and the insert/query/delete chain against testexdb completing. To switch targets, add the extdb.archive.* set, change mysqlroute.target.datasource from primary to archive, reload, and the target= field in the log follows the new id.
When the bean is not there
"No bean could be found in the registry" means the naming contract broke somewhere: check that system.components includes externaldb, extdb.enabled=true, the target id is listed in extdb.ids, and the SQL URI really spells extdb-<id>-datasource. If the health check runs but SQL fails, check the URL, driver, and credentials, that the testexdb table exists in the selected schema, and that the account has insert/select/delete permissions.
If a datasource switch does not take effect, confirm the new id's extdb.<id>.* set is fully configured, the service reload has completed, and the db.target header prints the expected id. And if the default surprises you, remember the order: the route-level mysqlroute.target.datasource overrides extdb.default — without that override, the default id wins.