[jira] Commented: (AMQ-1232) ActiveMQ bridging - and how to set JMSDestination on a message when sending

["Thomas Roka-Aardal (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/AMQ-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39374 ] 

Thomas Roka-Aardal commented on AMQ-1232:
-----------------------------------------

Actually, this looks like a JMS 1.1 non-compliancy issue.

Setting the JMS destination on a foreign message _before_ transforming it to an ActiveMQ message is bound to fail, subject to the implementation on the foreign message.

I can confirm the same thing happens when attempting to use an activemq session to send a JBossMessaging message. When setting the destination it complains, since JBossMessage throws an exception when the destination is a non-JBM one.

Transforming _before_ setting the destination should fix this.

> ActiveMQ bridging - and how to set JMSDestination on a message when sending
> ---------------------------------------------------------------------------
>
>                 Key: AMQ-1232
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1232
>             Project: ActiveMQ
>          Issue Type: Wish
>          Components: Broker
>            Reporter: Alf E. Helseth
>
> Hi, 
> I've been trying to set up ActiveMQ 4.1.1 as a bridge over to Sun's STC message broker used in the Sun CAPS Integration platform system.
> Got it to work with using the ConnectionFactory from CAPS and by specifying the following in the activemq.xml -file:
>   <bean id="remoteFactory"
>      class="com.stc.jms.client.STCQueueConnectionFactory">
>     <constructor-arg value="localhost"/>
>     <constructor-arg value="18007"/>
>   </bean>
> The connection works, but AMQ fails when trying to bridge message from CAPS to AMQ (the other direction works fine).
> The fail is materialized in a ClassCastException thrown from line 1505 in the class ActiveMQSession, in the statement:
>         message.setJMSDestination(destination);
> The actual message instance is inherited from Sun's com.stc.jms.message.STCMessage, and the implementation of the setJMSDestination()-method here is doing a cast on the destination to a STCDestination, wich it really isn't, and thus generating the Exception.
> My question however, is why this call to setJMSDestination is done on the original message? 
> I see further down the AMQ send()-method that a new message is created (returned from ActiveMQMessageTransformation.transformMessage() on line 1524) and this is the one that really is sent. If setJMSDestination() is called on _this_ message instead, it all works fine (since this is a "native" AMQ message).
> I've tried this out on my own local AMQ installation, just by replacing the ActiveMQSession- class in the origin jar-file (activemq-core-4.1.0-incubator.jar).
> The only change is to remove the line on 1505 as mentioned above, and instead call 
>  msg.setJMSDestination(destination);
> - somewhere below line 1524, after creating the new msg from the transformMessage()-call.
> This is a suggestion from my point-of-wiew, but maybe this approach will generate some kind of side-effects that I'm not aware of.
> Otherwise this relatively small change will (imho) make ActiveMQ be better suitable to bridge to other JMS-brokers.
> Regards
> -Alf

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.