CachedMessageProducer does not support all JMS 2.0 MessageProducer methods [SPR-11950]

[spring-projects-issues]

Christopher Shannon opened SPR-11950 and commented

#16566 fixes CachedMessageProducer so that Jms2MessageProducerInvocationHandler properly delegates calls to CachedMessageProducer.this.

However, only 2 out of the 4 new methods are supported that exist in the JMS 2.0 MessageProducer interface.

The following 2 methods are not supported by the proxy:

send(Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

For example, when attempting to execute one of these methods the following error occurs:

java.lang.AbstractMethodError: org.springframework.jms.connection.CachedMessageProducer.send(Ljavax/jms/Destination;Ljavax/jms/Message;IIJLjavax/jms/CompletionListener;)V
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.jms.connection.CachedMessageProducer$Jms2MessageProducerInvocationHandler.invoke(CachedMessageProducer.java:287)
.......

---

Affects: 4.0.5

Issue Links:

• #16566 CachingConnectionFactory doesn't properly cache producers with JMS 2.0

[spring-projects-issues]

Stéphane Nicoll commented

The root of the problem is that we can't easily test JMS 2.0 specific methods. I'll research what we can do to avoid that kind of inconsistency in the future.

[spring-projects-issues]

Stéphane Nicoll commented

Thanks for the report. This is now fixed in master.

Juergen Hoeller, I guess this should go in your backport list.

I have added some integration tests before fixing those methods and made sure they were failing as you mentioned. Unfortunately, we can't use both the JMS 1.1 and 2.0 APIs in the same project. I have started to craft an integration test infrastructure for the framework, you can find that in 1a66915

[spring-projects-issues]

Juergen Hoeller commented

This is a kind of side effect of #16566: When delegating to the broker's actual Provider implementation (which is JMS 2.0 compliant in such a case), we don't need to specifically handle all CompletionListener call variants - we just need to intercept the ones with custom configuration settings. However, with #16566's resolution, we are delegating to Spring's own CachedMessageProducer which doesn't implement any JMS 2.0 CompletionListener methods, so indeed, now we need to specifically handle all of Producer's JMS 2.0 methods there.

I'm backporting this to 4.0.6 now, just like #16566.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

This will be available in the upcoming 4.0.6.BUILD-SNAPSHOT. Feel free to give it a try, Christopher...

Juergen

[spring-projects-issues]

Christopher Shannon commented

Thanks for the quick response guys...I was going to submit a pull request for this issue this morning but I woke up and it was already fixed. The integration test is essentially what I did last night. I just added the jms 2.0 api and used mockito to mock out everything to prove that those methods would in fact fail. Unfortunately, #16566 wouldn't fail with a mock...a real broker would probably be needed to catch this kind of bug.

I did some research and it looks like Glassfish MQ 5 does support JMS 2.0 if you were looking for a real broker to test against. Besides Tibco EMS, our team also uses ActiveMQ but that broker does not support JMS 2.0 yet.

Since our team uses Spring's JMS support heavily (JmsTemplate, DefaultMessageListenerContainer, etc),I will go back and try everything out with our Tibco broker and create new issues if I come across any problems.

Chris

[spring-projects-issues]

Stéphane Nicoll commented

that's awesome Chris, thanks a lot! You can also use HornetQ if you want to test against a JMS 2.0 broker.