davsclaus opened a new pull request, #28213:
URL: https://github.com/apache/camel/pull/28213
A tool that watches a running Camel app (the Camel CLI, the MCP tools, an
IDE, an AI agent) knows the routes by id and file. After a restart or a reload
it cannot tell which routes changed: every route of a file comes back under the
same file name, and a generated id such as `route3` may now belong to another
route. This gives each route two values, shown the same way everywhere
(CAMEL-25771).
**Checksum**: a short hex digest (12 characters of a SHA-256) of the route
as written:
- It covers the route's steps, their options and expressions, with property
placeholders as written.
- It leaves out:
- the ids Camel generates;
- the source locations, so moving a route in its file or adding a route
above it keeps the checksum;
- the `onException`, `intercept` and `onCompletion` that route
configurations add to every route, so one edit to a shared configuration does
not mark every route changed. The `onException` of the route itself is part of
it.
- The same route gives the same checksum in every run.
**Revision**: a counter per route id in the running app.
- It is 1 when the route is added, one more each time it is added again with
another checksum, and unchanged when it comes back the same.
- It survives the route being removed and added again, and starts over when
the app restarts. Across restarts, tools compare checksums.
**How**
- A new SPI, `ModelChecksumGenerator` (camel-api, `@since 4.24`), computes
the checksum when a route is prepared, before the route configurations are
merged in (`RouteDefinitionHelper.prepareRoute`).
- It is implemented only in camel-xml-io, where the generated `ModelWriter`
writes every option of the model straight into the digest. That is a single
implementation on purpose:
- camel-xml-io and camel-xml-jaxb both register the XML dumper, so hashing
the dumper's output would depend on the classpath order;
- the dumper also writes source locations while debugging.
- The checksum is null without camel-xml-io, which comes with camel-core,
camel-management and the CLI connector. Wherever the checksum can be seen (JMX,
the consoles, the Camel CLI) it is there.
- `LwModelToXMLDumper` now shares its writing with the generator: a refactor
with no change to the dumps (the camel-xml-io tests and the route dump tests
pass).
**Where it shows**
- `Route.getChecksum()` / `getRevision()` and `NamedRoute.getChecksum()`, as
default methods, `@since 4.24`.
- JMX: the `Checksum` and `Revision` attributes of a managed route.
- Developer consoles: `checksum` and `revision` per route in the `route`
console. The CLI status file and the MCP `camel_runtime_routes` tool read that
console as is, so they have them with no extra code. The `route-structure` and
`route-dump` consoles have the checksum of each route.
- Camel CLI: `camel get route` and `camel top route` have both in their
JSON, and as columns with `--checksum`.
- Camel CLI: `camel cmd route-structure <file>` gives the checksum of each
route of a source file without running it, and it is the checksum the route has
when it runs:
- YAML and XML are loaded as a running app loads them;
- a Java source read by the Java DSL parser gets the checksum when the
parser read all of it.
The JSON route dump (`camel.main.dumpRoutes=json`) has the checksum too.
- The reload summary: `Routes reloaded summary (total:3 started:3
changed:2)`, with `(changed)` or `(new)` on each route the reload changed.
- MCP: the descriptions of `camel_runtime_routes` and
`camel_runtime_route_structure` say how to use the checksum.
**Cost**: measured on 1000 routes with a choice, a split and a filter each:
about 12 µs a route after warm-up, about 12 ms in all, so it is computed always.
**Limits**, documented in the routes page:
- The checksum covers the route, not the code it calls: a Java lambda in
`.process(...)` dumps as a bare `process`, and a change inside a bean is not
seen.
- A changed property value is configuration, not a changed route.
- A route with a generated id should be matched by its checksum.
**Tests**
- `RouteChecksumTest` (camel-core):
- the same route gets the same checksum in two contexts; an edited
endpoint or EIP option changes it;
- generated ids, a route configuration's `onException`, placeholder values
and debugging (with source locations) do not change it, while the route's own
`onException` does;
- the revision counts only real changes.
- `RouteWatcherReloadChangedRoutesTest`: the reload summary, its changed and
new markers, and `changed:0` when a file is saved again as it was.
- `RouteActionJavaSourceTest`: a Java route read by `camel cmd
route-structure` without compiling it has the checksum of the same route
compiled and added to a CamelContext.
- `ManagedRouteChecksumTest`, `RouteChecksumDevConsoleTest`, and a new case
in `CamelRouteStatusTest`.
- Test suites:
- camel-xml-io: 434 tests pass.
- camel-jbang-core: 2639 tests pass.
- camel-core: 8258 of 8260 pass. The two failures,
`JsonDataFormatReifierTest` for Gson and Jsonb, fail on main too, and #28208
fixes them.
- Checked live with the Camel CLI on this branch, with `orders.camel.yaml`:
- read with `camel cmd route-structure` and running (`camel get route
--checksum`), it gives the same checksum;
- after an edit, the dev mode reload gives both the new checksum, and the
route is at revision 2.
Next, in follow-ups:
- the source editor view of CAMEL-25897, which waits for this, can say per
route whether the editor has the version that runs;
- `camel validate` can use a running integration's body types only for the
routes whose checksum did not change.
_Claude Code on behalf of davsclaus_
🤖 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]
