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.
