Camel Quarkus 3.40.0 Migration Guide

quarkus.camel.ldap.dir-contexts."name".security-authentication previously defaulted to none, which was put into the JNDI environment for every directory context whether or not it had been configured. Its documentation has always said that the behaviour is determined by the service provider when the property is unspecified, and it is now the only option in that configuration group without a default, matching initial-context-factory, provider-url, security-protocol and socket-factory.

The property is now only placed into the JNDI environment when it is configured, so the service provider decides otherwise.

This matters where credentials are supplied through additional-options, which is the only way to pass them. Previously none was already in the environment, and supplying only a principal and credentials left the bind anonymous with the credentials ignored. They now take effect.

To keep the previous behaviour for a context that relied on the default, set it explicitly.

The bridge that exposes ai-tool: routes to LangChain4j AI services was part of camel-quarkus-support-langchain4j, an internal artifact that applications had to declare by hand alongside camel-quarkus-ai-tool. It is now part of camel-quarkus-ai-tool itself, and that dependency can be removed.

The @CamelAiTools annotation moved with it. Update the import.

The bridge is registered when camel-quarkus-ai-tool is a dependency and Quarkus LangChain4j and camel-langchain4j-agent are on the classpath. Applications that used ai-tool: routes without declaring camel-quarkus-ai-tool must now add it. A warning naming the affected tools is logged at startup when they are registered without it. Its behaviour is otherwise unchanged.

TransactionalJtaTransactionPolicy, the base class of all six PROPAGATION_* policies, logged a warning and carried on when rollback(), setRollbackOnly() or resume() failed. A route that handled the original exception could therefore continue as though the transaction had been marked for rollback when it had not, and work after a failed resume ran outside the transaction the policy was expected to restore.

These failures are now raised:

An application that inspected only the top-level exception sees no difference. One that handles exceptions and continues may now see a failure it previously never learned about. Check Throwable.getSuppressed() when diagnosing.

No method signatures changed. resumeTransaction(Transaction) is unchanged and now wraps a resume failure in a RuntimeCamelException; a new resumeTransaction(Transaction, Throwable) overload is what the policies use so that a resume failure cannot replace a failure already on its way out.

quarkus.camel.native.reflection.serialization-enabled previously defaulted to false, but a false value carried no meaning of its own. Extensions that require Java serialization to work, such as camel-quarkus-jms, camel-quarkus-jolt, camel-quarkus-management, camel-quarkus-netty, camel-quarkus-sjms, camel-quarkus-sjms2 and camel-quarkus-sql, registered the base set of classes for serialization on being present on the classpath, and there was no way to prevent it.

The option is now unset by default and has three states:

Setting the option to false therefore now bounds what the native image is able to deserialize, at the cost of breaking any component that depends on Java serialization. A build that requests the veto while extensions ask for serialization logs a warning.

Applications that set the option to false while relying on one of the extensions above must remove the setting to keep working. Applications that set it to true, or that never set it, are unaffected.

Converting a Quarkus TLS configuration to SSLContextParameters previously carried over only the key and trust material. quarkus.tls.protocols, quarkus.tls.cipher-suites and quarkus.tls.key-exchange-groups were dropped, so Camel components using a registered bean negotiated with the JVM defaults rather than the policy that had been configured for them. Quarkus keeps those alongside the Vert.x transport options and never applies them to the SSLContext itself, so nothing carried them across and nothing warned that they had been lost.

All three are now applied to every SSLEngine and socket factory Camel derives from a registered bean.

quarkus.tls.protocols defaults to TLSv1.3, so a bean that previously offered whatever the JVM enabled now offers TLSv1.3 alone, matching every other consumer of the same TLS configuration. Where a route talks to an endpoint that does not support TLSv1.3, widen the property.

Note that this applies to the whole TLS configuration, not only to Camel. Define a named configuration for the endpoint that needs it if the rest of the application should stay on TLSv1.3.

Camel applies a configured list verbatim rather than reducing it to what the JVM supports, so a name the JVM does not recognise now fails the creation of the SSL context instead of being ignored. Disabled but known names, such as SSLv3, are still accepted.

This affects a configuration that sets quarkus.tls.<name>.ssl-engine to openssl and names cipher suites in OpenSSL style, which Vert.x accepts. Use the JSSE names for a configuration that Camel components consume.

Note also that a configured list takes precedence over Camel’s own default exclusion filters. Because quarkus.tls.protocols always carries a value, those filters do not exclude the SSLv2 and SSLv3 protocols from a bridged configuration, and they exclude the NULL, anon, EXPORT, DES, MD5 and RC4 cipher suites only while quarkus.tls.cipher-suites is unset.

certificate-revocation-list, hostname-verification-algorithm, key-store.sni, alpn and pqc-enforcement-policy have no equivalent in SSLContextParameters and are still not carried over. They remain the responsibility of the consuming Camel component or endpoint, and continue to apply to Quarkus’s own TLS consumers as before.

A warning is now logged at startup for the two that weaken verification if the operator assumes otherwise, instead of them being dropped silently. In particular, a Camel component using a bridged bean does not check certificate revocation, and so accepts a revoked certificate that the rest of the application rejects.

Refer to the TLS Registry extension documentation for details.

Documents being transformed are now parsed with an XMLReader that does not resolve external general entities, so a SYSTEM entity in a DOCTYPE declaration no longer expands into the transformation result.

Most routes see no change, because camel-xslt already converts String, byte[] and InputStream bodies through Camel’s own hardened parser before the transformer sees them. The change matters where the body reaches the transformer already shaped as a Source, for example after convertBodyTo(Source.class) or from a component that produces one, and for code calling the factory directly.

A SAXSource carrying an XMLReader the caller configured is passed through untouched, so an application that needs different parsing rules can supply its own reader.

DOMSource and StAXSource bodies are parsed before they reach the transformer and are unaffected.

Resources fetched at transform time by the XSLT document() function are now denied unless the application’s own javax.xml.transform.URIResolver resolves them, which is what the JDK does when secure processing is enabled.

Routes are unaffected. camel-xslt installs a URIResolver on every transformer it uses, so document() continues to resolve exactly as it did, and as it does on plain Camel. The change affects code that uses the JAXP default factory directly and relies on document() without setting a resolver.

The restriction applies to every entry point that hands out something to transform with, so code driving the SAX push API through newTransformerHandler() or newXMLFilter() is restricted in the same way, including the Transformer reached through TransformerHandler.getTransformer().

Because the restriction is carried by a URIResolver rather than by a factory attribute Xalan cannot honour, it survives the two things that would otherwise remove it: Transformer.reset() keeps it, and setURIResolver(null) falls back to it rather than lifting it. An application that needs document() to resolve sets a resolver of its own, as before.

xsl:import and xsl:include are unchanged. Xalan dereferences those hrefs itself while compiling a stylesheet, ignoring the resolver it consulted first, so they cannot be restricted here. Stylesheets are deployment owned rather than attacker controlled, and camel-xslt resolves includes through its own unrestricted resolver in any case.

quarkus.camel.xslt.features was only applied to templates that were compiled to a translet at build time, which is classpath: templates. It was silently ignored for templates loaded at runtime, which is the remaining schemes in JVM mode. It is now applied to every template the component transforms with.

A feature that previously had no effect on those endpoints now takes effect, and one the TransformerFactory does not support now fails endpoint creation rather than passing unnoticed. Review the property if it is set for an application that transforms with templates loaded at runtime.

Disabling secure processing also now logs a warning on startup, since it permits templates to call Xalan extension functions.