activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alf E. Helseth (JIRA)" <>
Subject [jira] Created: (AMQ-1232) ActiveMQ bridging - and how to set JMSDestination on a message when sending
Date Thu, 19 Apr 2007 08:34:35 GMT
ActiveMQ bridging - and how to set JMSDestination on a message when sending

                 Key: AMQ-1232
             Project: ActiveMQ
          Issue Type: Wish
          Components: Broker
            Reporter: Alf E. Helseth


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"
    <constructor-arg value="localhost"/>
    <constructor-arg value="18007"/>

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:


The actual message instance is inherited from Sun's, 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 


- 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.


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

View raw message