[
https://issues.apache.org/jira/browse/CAMEL-25142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25142:
--------------------------------
Description:
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 is reified, so the steps of
an interceptFrom may not be intercepted (from reading the code, not verified).
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_
was:
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_
> 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
> Assignee: Claus Ibsen
> Priority: Major
> 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 is reified, so the steps
> of an interceptFrom may not be intercepted (from reading the code, not
> verified).
> 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)
