You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Alf E. Helseth (JIRA)" <ji...@apache.org> on 2007/04/19 10:34:35 UTC

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

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.


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

Posted by "James Strachan (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQ-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Strachan resolved AMQ-1232.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0.0

Many thanks for this excellent analysis folks. Patch applied to trunk with thanks. (rev: 546847. By all means try it out by building trunk or waiting for tomorrows 5.0-SNAPSHOT build)

http://people.apache.org/repo/m2-snapshot-repository/org/apache/activemq/apache-activemq/



> 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
>            Assignee: James Strachan
>             Fix For: 5.0.0
>
>
> 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.


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

Posted by "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.


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

Posted by "James Strachan (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/activemq/browse/AMQ-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Strachan reassigned AMQ-1232:
-----------------------------------

    Assignee: James Strachan

> 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
>            Assignee: James Strachan
>
> 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.