Exception Resolving RMQConnectionFactory from WildFly 16.0.0 JNDI about rabbitmq-jms-client HOT 2 CLOSED

The commit above simply added a new field. If there was a serialised version of a com.rabbitmq.jms.admin.RMQConnectionFactory stored somewhere, it is likely not going to deserialise successfully. There is no way this client can work around that and not adding new fields is not an option.

Please start a mailing list thread with an example repository we can use to reproduce. We'd like to support WildFly 1.10 but the change is quite trivial and there can be data from older versions involved.

from rabbitmq-jms-client.

I think the serialization crashes because the default, no-op value for RMQConnectionFactory#amqpConnectionFactoryPostProcessor is not serializable. Versions after 1.9 introduced a few other properties to RMQConnectionFactory and their default, no-op values are not serializable (metricsCollector, amqpConnectionFactoryPostProcessor, sendingContextConsumer, receivingContextConsumer).

The easiest workaround is to assign null values to these properties. They should be null-proof, except metricsCollector, but you can give it a try. The next workaround is to assign no-op values that implements serializable (create such classes and assign instances of them to the connection factory).

These are just temporary workarounds to make sure my assumption is correct, we can obviously make those default implementations serializable and specify in the Javadoc that the instances for these properties must be serializable in some specific environments (e.g. JNDI).

Problem solved if WildFly needs the connection factory to be serializable for some reasons (e.g. transmitting it over the network). The problem is different with the following scenario: the connection factory is serialized (stored somewhere) with some JMS Client version and then must be deserialized (read from storage) and restored with another JMS Client version. This isn't only about serialization anymore, but also about the compatibility of serialization between versions. This can be solved as well but seems overkill for this case.

Thanks for the provided information, I would not mind a sample project and instructions to reproduce and check some potential fixes (I'm not familiar with WildFly).

Important note: I see you use the AMQP Client 5.7.0. The 1.x series of the JMS client are compiled against the 4.x series of the AMQP client (to keep the compatibility with Java 1.6). AMQP client 4.x and 5.x are not compatible, so there's no guarantee that JMS Client 1.x works with AMQP Client 5.x. You should use AMQP Client 4.8.3 with JMS client 1.11.2 (or the latest of AMQP Client 4.x, that is 4.11.0 right now).

from rabbitmq-jms-client.