Claus Ibsen created CAMEL-25142:
-----------------------------------
Summary: camel-core - Late binding of onException, interceptors,
onCompletion and route configurations, so they keep working when routes and
configurations change at runtime
Key: CAMEL-25142
URL: https://issues.apache.org/jira/browse/CAMEL-25142
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Fix For: 4.24.0
The cross-cutting features (onException, error handler, intercept,
interceptFrom, interceptSendToEndpoint, onCompletion) and the route
configurations that hold them are bound to the routes when the routes are
created. This performs well, but it does not keep working when the routes or
the configurations change while Camel runs, which the more dynamic and low-code
use of Camel (dev reload, adding/removing routes, restarting the CamelContext,
route configurations managed by tooling) needs.
h3. How it works today
* *Model time:* when a route is prepared, the builder-level definitions and the
matching route configurations are merged into the route's outputs
(RoutesDefinition.prepareRoute, RouteDefinitionHelper.prepareRoute). The
definition objects are shared by all the routes, and a route is prepared only
once (isPrepared).
* *Reify time:* each route builds its own processors from them. onException
becomes exception policies in an error handler, and the error handler is
created per Channel (per EIP node), each with its own policy map. intercept
becomes an InterceptStrategy that wraps each Channel when the Channel is built.
onCompletion becomes route processors. interceptSendToEndpoint wrapped
endpoints (see CAMEL-25140).
* *After that the binding is fixed:*
** adding/removing a route configuration at runtime (ModelCamelContext) only
changes the list; the routes that use it are not updated.
** dev reload works because it removes all the routes and loads all the files
again (removeAllRoutes=true). With removeAllRoutes=false, routes in other files
keep the old configuration. Route configurations removed from a file are never
removed.
** a CamelContext restart creates the routes again from the prepared
definitions, but intercept and interceptSendToEndpoint removed their
definitions from the route outputs, so they are lost (interceptSendToEndpoint
is fixed in CAMEL-25140).
** intercept only wraps the Channels built after it, so interceptFrom and
interceptSendToEndpoint steps are not intercepted (from reading the code).
Related older tickets: CAMEL-18923 (updating a route configuration is not
supported, as it is global and affects running routes), CAMEL-5629 (adding an
intercept at runtime), CAMEL-3870 (reusable onExceptions, which led to route
configurations), CAMEL-13912 (create error handlers when reifying rather than
at runtime, for performance), CAMEL-25140, CAMEL-25141.
h3. Goal
Bind the cross-cutting features late: keep them in a registry of the
CamelContext (by route configuration / RouteBuilder), and let the routes
resolve what applies to them, with a cheap check on the hot path (such as a
generation counter that is bumped when a configuration changes, and routes
resolve again lazily). The per-message decision (which exception, onWhen,
pattern) stays as today; only the wiring becomes dynamic. The order of
precedence (route, then RouteBuilder, then route configuration) must stay
exactly as today.
h3. Plan
A design document in design/ (cross-cutting-binding.adoc) with the current
state per feature and the proposed model. Then, in steps:
# route configurations (the unit for low-code): updating/removing one updates
the routes that use it
# onException / error handler (policies resolved from the registry instead of
copied per Channel; ties in with CAMEL-24980)
# intercept / interceptFrom
# onCompletion
If this can be done without invasive changes, it is a goal for Camel 4.24. If
it turns out to need API or behaviour changes, it becomes a goal for Camel 5.0.
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
