#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:
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)
#16566 CachingConnectionFactory doesn't properly cache producers with JMS 2.0
The text was updated successfully, but these errors were encountered:
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
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.
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.