1.8.0.RC1

Changes between 1.7.0 and 1.8.0.RC1

This is a release candidate for 1.8.0, a maintenance release that includes a new option and an upgrade of the RabbitMQ Java client dependency. This release is backward-compatible with 1.7.0.

Add option to clean up server-named queues for non-durable topics on session closing

Those queues would be cleaned only on connection closing, now they can be closed on session closing by setting RMQConnectionFactory#cleanUpServerNamedQueuesForNonDurableTopicsOnSessionClose to true. Default is false.

Thanks to @AlexShvedoff for this contribution.

GitHub pull request: #35

Upgrade to RabbitMQ Java Client 4.3.0

The JMS Client now uses RabbitMQ Java Client 4.3.0.

GitHub issue: #37

1.7.0

Changes between 1.6.0 and 1.7.0

This is a maintenance release that includes bug fixes, enhancements, and an upgrade of the RabbitMQ Java client dependency. This release is backward-compatible with 1.6.0.

Let RMQObjectFactory handle properties from a hash table

It's now possible to provide all required properties via the Hashtable environment third argument of RMQObjectFactory#getObjectInstance() method. This allows the user to create client objects on WildFly via Naming subsystem configuration.

Thanks to Rémi Bantos for this contribution.

GitHub issue: #21

Add option to take message properties into account on sending

It's now possible with the RMQConnectionFactory#preferProducerMessageProperty flag set to false to take into account the JMS Message properties (priority, delivery mode, expiration date) on sending. Note this isn't compliant with the JMS specification (the default behavior follows the JMS specification).

GitHub issue: #26

Add option to requeue message on client runtime exception

The JMS specification tells to requeue a message if the client throws a RuntimeException during delivery. The RabbitMQ JMS client wouldn't do that, it would just cancel the listener. We consider this behavior to be more natural, especially when using auto-acknowledgment mode. Nevertheless, the RMQConnectionFactory#requeueOnMessageListenerException allows to comply to the specification when set to true. The default is false (dropping the message), but this default could change in the next major release.

GitHub issue: #23

Upgrade to RabbitMQ Java Client 4.1.1

The JMS Client now uses RabbitMQ Java Client 4.1.1.

GitHub issue: #18

Don't fail when sending an empty message

GitHub issue: #24

Make compliance test suite pass again

A security fixed introduced a bug that would make the Compliance Test Suite fail. This is now fixed, the CTS passes.

GitHub issue: #16

1.7.0.RC2

Changes between 1.6.0 and 1.7.0.RC2

This is a release candidate for 1.7.0, a maintenance release that includes bug fixes, enhancements, and an upgrade of the RabbitMQ Java client dependency. This release is backward-compatible with 1.6.0.

Let RMQObjectFactory handle properties from a hash table

It's now possible to provide all required properties via the Hashtable environment third argument of RMQObjectFactory#getObjectInstance() method. This allows the user to create client objects on WildFly via Naming subsystem configuration.

Thanks to Rémi Bantos for this contribution.

GitHub issue: #21

Add option to take message properties into account on sending

It's now possible with the RMQConnectionFactory#preferProducerMessageProperty flag set to false to take into account the JMS Message properties (priority, delivery mode, expiration date) on sending. Note this isn't compliant with the JMS specification (the default behavior follows the JMS specification).

GitHub issue: #26

Add option to requeue message on client runtime exception

The JMS specification tells to requeue a message if the client throws a RuntimeException during delivery. The RabbitMQ JMS client wouldn't do that, it would just cancel the listener. We consider this behavior to be more natural, especially when using auto-acknowledgment mode. Nevertheless, the RMQConnectionFactory#requeueOnMessageListenerException allows to comply to the specification when set to true. The default is false (dropping the message), but this default could change in the next major release.

GitHub issue: #23

Upgrade to RabbitMQ Java Client 4.1.1

The JMS Client now uses RabbitMQ Java Client 4.1.1.

GitHub issue: #18

Don't fail when sending an empty message

GitHub issue: #24

Make compliance test suite pass again

A security fixed introduced a bug that would make the Compliance Test Suite fail. This is now fixed, the CTS passes.

GitHub issue: #16

1.7.0.RC1

Changes between 1.6.0 and 1.7.0.RC1

This is a release candidate for 1.7.0, a maintenance release that includes a bug fix, an enhancement, and an upgrade of the RabbitMQ Java client dependency. This release is backward-compatible with 1.6.0.

Let RMQObjectFactory handle properties from a hash table

It's now possible to provide all required properties via the Hashtable environment third argument of RMQObjectFactory#getObjectInstance() method. This allows the user to create client objects on WildFly via Naming subsystem configuration.

Thanks to Rémi Bantos for this contribution.

GitHub issue: #21

Upgrade to RabbitMQ Java Client 4.1.0

The JMS Client now uses RabbitMQ Java Client 4.1.0.

GitHub issue: #18

Make compliance test suite pass again

A security fixed introduced a bug that would make the Compliance Test Suite fail. This is now fixed, the CTS passes.

GitHub issue: #16

1.6.0

Changes between 1.5.0 and 1.6.0

This is a release candidate for 1.6.0, a maintenance release that includes a few bug fixes, enhancements, and an upgrade of the RabbitMQ Java client dependency. This release is backward-compatible with 1.5.0.

Refactor RMQConnection and RMQSession to accept fewer constructor parameters

This is an internal refactoring to make it easy to add new settings to JMS resources.

GitHub issue: #7

Provide a way to configure onMessageTimeoutMs

It is now possible to configure the message processing timeout.

GitHub issue: #5

Contributed by Guillaume Mornet.

Support hostname lists

It is now possible to provide a list of hostnames to connect to (instead of a single one).

GitHub issue: #2

Upgrade to RabbitMQ Java Client 4.0

The JMS Client now uses RabbitMQ Java Client 4.0.

GitHub issue: #9

Set consumer prefetch (a.k.a QoS)

RMQConnectionFactory has a new property to set up the quality of service on created channels. This make it easy to balance load between consumers.

GitHub issue: #11

Provide a way to configure TLS options for JMS connections

RMQConnectionFactory provides some methods to finely-tune the underlying SSLContext for TLS connections.

GitHub issue: #1

SSLContext was overridden with default

Provided SSLContext was overridden because of a side-effect in a method call in the RabbitMQ Java Client. The SSLContext provided to the RMQConnectionFactory is now effectively used.

GitHub issue: #12

Allow using default SSLContext

RMQConnectionFactory has now a flag to use the default SSLContext. It is thus possible to set up TLS options (e.g. key store and trust store) from the command line, with system properties.

GitHub issue: #14

1.6.0.RC1

Changes between 1.5.0 and 1.6.0.RC1

This is a release candidate for 1.6.0, a maintenance release that includes a few bug fixes, enhancements, and an upgrade of the RabbitMQ Java client dependency. This release is backward-compatible with 1.5.0.

Refactor RMQConnection and RMQSession to accept fewer constructor parameters

This is an internal refactoring to make it easy to add new settings to JMS resources.

GitHub issue: #7

Provide a way to configure onMessageTimeoutMs

It is now possible to configure the message processing timeout.

GitHub issue: #5

Support hostname lists

It is now possible to provide a list of hostnames to connect to (instead of a single one).

GitHub issue: #2

Upgrade to RabbitMQ Java Client 4.0

The JMS Client now uses RabbitMQ Java Client 4.0.

GitHub issue: #9

Set consumer prefetch (a.k.a QoS)

RMQConnectionFactory has a new property to set up the quality of service on created channels. This make it easy to balance load between consumers.

GitHub issue: #11

Provide a way to configure TLS options for JMS connections

RMQConnectionFactory provides some methods to finely-tune the underlying SSLContext for TLS connections.

GitHub issue: #1

SSLContext was overridden with default

Provided SSLContext was overridden because of a side-effect in a method call in the RabbitMQ Java Client. The SSLContext provided to the RMQConnectionFactory is now effectively used.

GitHub issue: #12

Allow using default SSLContext

RMQConnectionFactory has now a flag to use the default SSLContext. It is thus possible to set up TLS options (e.g. key store and trust store) from the command line, with system properties.

GitHub issue: #14

1.5.0

Changes Between 1.4.7 and 1.5.0

1.5.0 is a maintainence release that includes a fix
for CVE-2016-6194.

Limited ObjectMessage Deserialization

Classes that can be deserialized from javax.jms.ObjectMessage
now can be limited via a package prefix white list.
There are two ways to do it:

• Via the com.rabbitmq.jms.TrustedPackagesPrefixes JVM property which accepts
  a comma separated list of prefixes, for example, java,com.rabbitmq,com.mycompany
• Using RMQConnectionFactory#setTrustedPackages, RMQConnection#setTrustedPackages, or RMQSession#setTrustedPackages
  which accept lists of package prefixes

All options take a list of package name prefixes, e.g. java will make all classes
in java.lang, java.util, and other packages starting with java trusted.
Deserialization attempt for untrusted classes will throw an exception.

GH issue: rabbitmq-jms-client#3.

This fixes CVE-2016-6194 (note: attacker must be authenticated
with RabbitMQ in order to carry out the attack).

RabbitMQ Java Client Dependency Update

This client now depends on RabbitMQ Java client 3.6.3.