denis256 notes and projects

Apache Camel is an integration framework for routing, mediation, and application glue code that people keep in production for years. The last seven days were busy: 163 commits, a lot of camel-jbang TUI work, and one large Splitter EIP change that matters if Camel is part of your batch style processing path. The headline is practical: the command line tooling is getting better at live operations while the routing model gets more control over chunks, failures, and resume state.

The camel-jbang TUI is becoming an ops console

The biggest visible theme is camel-jbang. Many of the top touched files sit under the TUI package, including CamelMonitor, ActionsPopup, OverviewTab, and TabRegistry. That is a useful signal. This is not just cosmetic terminal polish. The TUI is turning into a local control plane for a running integration.

The sharpest addition is the CVE Audit tab. It scans classpath dependencies through the OSV.dev batch API, groups findings by severity, and shows details such as CVSS vectors and affected artifacts. It also caches data across tab visits and rescans when the selected integration changes.

For operators, this is a good local warning layer. It is not a reason to delete CI scanning. It is a fast way to notice that the integration you are testing has a bad transitive jar before you hand it to a pipeline and wait for the usual slow answer.

Useful TUI changes from the same run include:

• The CVE Audit tab for dependency exposure checks
• Better popup navigation with PgUp, PgDn, Home, and End
• Substring filtering in the classpath view with /
• A more stable tab registry and less duplicate title noise

Splitter gets batch and failure controls

The most important routing change is the Splitter EIP enhancement. The commit adds group(int), errorThreshold(double), maxFailedRecords(int), resumeStrategy, and watermarkExpression. That is a real expansion of the Splitter contract, not a tiny DSL alias.

The useful part is that Splitter can now cover more bulk style work without a separate custom loop. group(int) turns split items into list batches. maxFailedRecords(int) gives a hard failure budget. errorThreshold(double) gives a ratio based stop rule. SplitResult records the outcome so callers can inspect total items, successes, failures, and abort state.

from("direct:start")
    .split(body()).group(100).maxFailedRecords(5)
        .to("bean:lineWorker")
    .end();

The practical advice is boring, which usually means it is correct. Prefer maxFailedRecords when you also use parallel processing. A ratio such as errorThreshold(0.5) can stop at slightly different points when parallel work completes in a different order. That is fine for some jobs, but it is annoying when you need repeatable abort behavior.

Runtime configuration gets easier to inspect

The TUI changes are also tied to runtime configuration. The new RuntimePropertiesProvider SPI gives PropertiesDevConsole a way to expose properties with their source. That matters when a route behaves differently under a profile, an environment override, or a generated runtime setting. Guessing where a value came from is a bad debugging ritual.

On the command side, the new --jvm-args support wires JVM arguments through Camel Main, Spring Boot, and Quarkus runs. The TUI run dialog also gained heap fields and validation in RunOptionsForm, so memory sizing is no longer a hidden launch detail.

camel run routes.yaml --jvm-args="-Xms128m -Xmx512m"

There is also a smaller but useful bean inspection change in the Beans and Threads tab refactor. BeansTab now keeps a detail panel visible and adds smarter filtering. ThreadsTab moves toward live inspection with automatic refresh and a visible stack trace panel.

Smaller fixes that reduce noisy failures

Several commits are stability work. This is the kind of activity that does not look impressive in a changelog but saves time for anyone building Camel often.

The mail MIME multipart fix filters Camel internal headers during unmarshal. If a MIME payload comes back through Camel, internal headers should not quietly become normal message headers. Small fix, good boundary.

The test suite also got more wait based fixes. BacklogTracerAggregateTest now waits for async tracer events, executor shutdown is forced through a finally block, and camel JPA tests moved from CountDownLatch toward Awaitility. There were also fixes for SQL, JMS, websocket, and JDK 25 file watcher flakes. Random red builds are expensive. This is maintenance, but it is not trivia.

What to watch

• Treat CVE Audit as a local signal, not the only security gate. It depends on the classpath view and OSV data.
• If you use Splitter for large lists, add tests for group, maxFailedRecords, and resume behavior before adopting them in a route with side effects.
• Expect more movement in camel-jbang. The touched TUI files show active work around popups, detail panes, folder browsing, and run configuration.