Camel Quarkus 3.40.0 Migration Guide

The following guide outlines how to adapt your code to changes that were made in Camel Quarkus 3.40.0.

LDAP extension changes

security-authentication is no longer defaulted to none

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.

quarkus.camel.ldap.dir-contexts."my-context".security-authentication=none

JTA extension changes

Rollback and resume failures are no longer swallowed

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:

  • A failure to roll back, or to mark an outer transaction for rollback, is attached to the exception that made the rollback necessary as a suppressed exception. That exception still propagates unchanged, so the failure is visible without hiding its cause.

  • A failure to resume a suspended transaction, in PROPAGATION_REQUIRES_NEW and PROPAGATION_NOT_SUPPORTED, is attached to the in-flight failure in the same way, or raised on its own when the body succeeded.

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.

Core extension changes

serialization-enabled can now veto extension serialization registrations

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:

  • When it is not set, classes are registered for serialization only if an extension on the classpath requires it. This matches the previous behaviour.

  • When it is true, the base set of classes is always registered. This is unchanged.

  • When it is false, nothing is registered for serialization, even if extensions on the classpath require it. This is new.

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.

Back to top