Announcement Announcement Module
Collapse
No announcement yet.
java.lang.UnsupportedOperationException during send with inbound-gateway Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • java.lang.UnsupportedOperationException during send with inbound-gateway

    I have written tree java classes and some spring config files which are all included in the attached zip,

    The JmsQueueSender sends 100 messages to queue.request and set the JMSReplyTo attribute to queue.reply.

    The ExampleListener is an MDB that reads the messages from queue.request. I have just added this to make sure the messages were actually send to the queue.request using the first class.

    The GatewayDemo and DemoBean I took from the samples of Spring integration.
    The inbound gateway reads the messages from queue.request and passes them to the DemoBean, which converts the String to uppercase. Because no reply channel is specified the messages go back to the the inbound gateway as expected.
    However I would expect the messages the be send to queue.reply, but instead I get the following exception:

    java.lang.UnsupportedOperationException
    at com.sun.messaging.jmq.jmsclient.MessageProducerImp l.send(MessageProducerImpl.java:730)
    at org.springframework.integration.jms.ChannelPublish ingJmsMessageListener.onMessage(ChannelPublishingJ msMessageListener.java:160)
    at org.springframework.jms.listener.AbstractMessageLi stenerContainer.doInvokeListener(AbstractMessageLi stenerContainer.java:518)
    at org.springframework.jms.listener.AbstractMessageLi stenerContainer.invokeListener(AbstractMessageList enerContainer.java:479)
    at org.springframework.jms.listener.AbstractMessageLi stenerContainer.doExecuteListener(AbstractMessageL istenerContainer.java:451)
    at org.springframework.jms.listener.AbstractPollingMe ssageListenerContainer.doReceiveAndExecute(Abstrac tPollingMessageListenerContainer.java:323)
    at org.springframework.jms.listener.AbstractPollingMe ssageListenerContainer.receiveAndExecute(AbstractP ollingMessageListenerContainer.java:261)
    at org.springframework.jms.listener.DefaultMessageLis tenerContainer$AsyncMessageListenerInvoker.invokeL istener(DefaultMessageListenerContainer.java:982)
    at org.springframework.jms.listener.DefaultMessageLis tenerContainer$AsyncMessageListenerInvoker.execute OngoingLoop(DefaultMessageListenerContainer.java:9 74)
    at org.springframework.jms.listener.DefaultMessageLis tenerContainer$AsyncMessageListenerInvoker.run(Def aultMessageListenerContainer.java:876)
    at java.lang.Thread.run(Thread.java:636)

    I am using Open MQ instead of Active MQ but I assume this isn't the cause because I have a similar error using Websphere MQ.

    Can somebody tell me what is going wrong here?

  • #2
    This looks like the same issue: http://jira.springframework.org/browse/INT-560

    Can you confirm that?

    Thanks,
    Mark

    Comment


    • #3
      This issue has been fixed. See the issue linked above for details.

      Regards,
      Mark

      Comment


      • #4
        The build status for this release is here:
        http://build.springframework.org/browse/INT-NIGHTLY-416

        The distribution snapshot is available under the 'artifacts' tab (and then the 'artifacts' link). It takes you here:
        http://build.springframework.org/dow...-416/artifacts

        Comment


        • #5
          With the latest distribution snapshot the code works correctly.

          I was wondering about the adding of the defaultReplyDestination attribute.
          Is or will it now be possible to do something like this :

          <jms:inbound-gateway id="jmsin"
          request-destination="requestQueue"
          default-reply-destination="replyQueue"
          request-channel="demoChannel"/>

          Or do you have to use some other way to inject the defaultReplyDestination into hannelPublishingJmsMessageListener?

          Comment


          • #6
            That's exactly what it *will* be. That should be available in tonight's build.

            These are the options that will be available:

            Destination reference:
            Code:
            <jms:inbound-gateway id="jmsin"
                    request-destination="requestQueue"
                    default-reply-destination="replyQueue"
                    request-channel="demoChannel"/>
            Queue name:
            Code:
            <jms:inbound-gateway id="jmsin"
                    request-destination="requestQueue"
                    default-reply-queue-name="replyQueue"
                    request-channel="demoChannel"/>
            Topic Name:
            Code:
            <jms:inbound-gateway id="jmsin"
                    request-destination="requestQueue"
                    default-reply-topic-name="replyTopic"
                    request-channel="demoChannel"/>
            In the latter two cases, a "destination-resolver" reference may also be provided, but the default is a DynamicDestinationResolver and should be fine for most scenarios (the JndiDestinationResolver is the other main option).

            In all of these cases, the JMS request Message's "JMSReplyTo" property will be given precedence. That is consistent with Spring's MessageListenerAdapter.

            Please let me know if you have any comments on this.

            Thanks,
            Mark

            Comment


            • #7
              Okay. These changes have been committed, so they are available on the SVN trunk and will be available in tonight's build at:
              https://build.springframework.org/browse/INT

              (i.e. it will be nightly build #417)

              Comment


              • #8
                hi guys,

                I also need this functionality, please provide details for downloading nightly build from svn.
                Also, where can I get a reference doc for ALL the tag values, or should I just use the schemas themselves?

                Comment


                • #9
                  found the nightly build artifact
                  just a matter of the tag reference doc, does the reference doc in the doc folder contain all the tags one can use? Or should one refer to the schemas themselves?

                  Comment


                  • #10
                    We add 'documentation' annotations to the schemas, so hopefully that is sufficient. The issue with documenting them in more than one place is that it risks synchronization issues between the docs. If you do find the schema's documentation lacking, please let us know.

                    The other main reason we prefer documenting the schema directly is that it is then available with the auto-completion capabilities of your IDE.

                    Comment

                    Working...
                    X