Camel 4.22 LTS is a migration checkpoint, not a feature-count release

Apache Camel 4.22.0 is the project’s new long-term-support release, but the useful signal is not the size of its resolved-issue list. The release notes show a platform tightening route security and operability while making AI integrations first-class parts of the routing model.

What changed

The largest architectural addition is a unified AI-tool abstraction for route-based tools. Camel can expose those routes through a built-in MCP server over Streamable HTTP, carry nested parameters as raw JSON Schema and attach MCP hints such as read-only, destructive and idempotent metadata. The same release adds OpenAI Responses API and audio operations, AWS Bedrock agent operations and more model choices in Camel’s terminal interface.

That AI work sits beside changes with broader production consequences. Camel 4.22 can apply an allow-list to dynamic-URI EIPs including toD, recipientList, routingSlip, dynamicRouter, enrich and pollEnrich. It can validate Keycloak token type and authorized-party claims, fail closed when platform HTTP JWT authentication lacks an issuer or audience, configure a JEP 290 object-input filter and strip path segments from externally derived filenames. JFR instrumentation now covers exchanges, processors and endpoints.

The release also fixes failure modes that can look like data loss rather than clean exceptions: S3 streaming uploads larger than the configured part size could be truncated, DDB Streams consumers could miss shards created after startup, and several AWS producers could silently do nothing when pojoRequest=true received the wrong body type.

Who should care

Teams maintaining integration routes should review the components they actually use rather than treating the resolved-ticket total as one risk class. AI-platform teams gain a path from existing routes to MCP tools, but the annotations are descriptive metadata; deployments still need policy enforcement around tool discovery and invocation.

For Red Hat build of Apache Camel users, this is upstream evidence, not a statement that 4.22 is already in a supported Red Hat stream. Adoption should follow Red Hat’s supported-version and compatibility guidance when product packaging catches up.

What to test

Camel supports Java 17, 21 and 25 in this release. A jump from an earlier LTS still crosses intermediate compatibility boundaries. Camel’s upgrade guidance says multi-minor moves require each intervening guide; among the documented changes, camel-exec now blocks control headers unless allowControlHeaders=true, JBang accepts route YAML only under route-specific naming conventions, and the Pulsar 4.2 client rejects old four-segment V1 topic names.

The practical migration plan is therefore component-led: inventory route schemes and dynamic endpoints, run regression tests for message delivery and error paths, check authentication and egress assumptions, and validate observability before promoting 4.22 as the next LTS baseline. The release page confirms the artifacts are available through Apache mirrors and Maven coordinates.