JBossDeveloper

 

"aslak" wrote:


1. The bridges source consumer receives a ActiveMQMessage from the ActiveMQProvider
2. The bridge tries to send the message to the target JbossProducer.
3. The JbossProducer figures out it is a foreign message and converts the message to a JbossMessage. The JbossProducers target JbossDestination is lost in the translation. (to be correct, the ActiveMQDestination is set on the JbossMessage and the ServerConnection failes casting it.)

Ok, I have quickly investigated this.

As you mention, the JBM message producer sets the JMSDestination before converting to a foreign message.

I haven't looked at the ActiveMQ code, but I can only assume that the Active MQ message ignores the set, resulting in the original non JBM destination existing at actual send time and the consequent exception.

It's probably not wise for JBM to assume the ActiveMQ message won't accept the set, so I think your fix of setting the destination after the conversion is valid.

I have replicated this locally with a foreign message that mimics the active mq behaviour and the fix seems to solve the problem.

I will commit this on TRUNK soon, and this will be in CR2.

 

"aslak" wrote:
Actually, the ActiveMQMessage converts the JbossDestination to a ActiveMQDestination. Then the ActiveMQMessage is converted to a JbossMessage with the ActiveMQDestination still set, hench the ClassCastException.


:o)

Ok fair enough. But the same fix should work in that case too. :)