Announcement Announcement Module
Collapse
No announcement yet.
JMS Message Selectors Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JMS Message Selectors

    I was able to configure a filter for the endpoint, but it picks up all messages off the queue and then simply discards the ones that do not pass the filter.

    I am looking for the ability to create a MessageSelector that will leave the filtering to the message server. I traced the code from the JmsMessageDrivenSourceAdapter up the call stack and see that I can set a selector inside the DefaultMessageListenerContainer.

    Now, I have the following 2 questions:
    1) Are there any plans for the Filter and Selector concepts to converge, whereby there is a JMS implementation of a filter which is a selector?
    2) In order to facilitate overriding JmsMessageDrivenSourceAdapter, can you make the container instantiation to be injected instead of instantiated? Also making the initialization/member variables protected would be very helpful too.

    Thanks,

    Vassil

  • #2
    I'd be very interested in a response to this from the SpringSource folks.

    Comment


    • #3
      The JmsMessageDrivenSourceAdapter does provide a "setContainer(AbstractMessageListenerContainer )" method. However, we should probably provide support for setting a JMS MessageSelector directly. Feel free to create an issue in JIRA: http://jira.springframework.org/browse/INT

      Thanks,
      Mark

      Comment


      • #4
        Is JMS Message Selector supported now in Spring Integration?
        I have a need for it and really appreciate if someone can provide an update.

        Ron

        Comment


        • #5
          The option for setting on a container instance and then referencing that from the endpoint should work fine. The issue that I mentioned above would just make that more convenient (a single attribute on the endpoint element instead of requiring the separate MessageListener container bean definition).

          Feel free to open that issue, and we'll address it for 2.0. In the meantime, you can set the selector on the container and reference that.

          Comment


          • #6
            Thanks Mark.

            With the following container configuration, the jms:message-driven-channel-adapter behaves as expected.

            Code:
               	<jms:message-driven-channel-adapter container="myContainer" channel="stout"/>
              	<stream:stdout-channel-adapter id="stout" append-newline="true"/>
            	<bean id="myContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
             		 <property name="connectionFactory" ref="connectionFactory" />
             		 <property name="destinationName" value="hello.queue" />
             		 <property name="messageSelector" value="myHeader = 'hello'"/>
             	</bean>
            But on the other hand, jms:inbound-channel-adapter ignores the selector set in the container and picks up all the messages sent to the queue regardless what value in the header property. A container is allowed to be configured in an JMS inbound channel adapter but behavior is not consistent. Is it improper use of JMS inbound channel adapter? or is it an issue? or should configuring a container in JMS inbound channel adapter be dis-allowed?

            inbound channel adapter configuration:
            Code:
              	<jms:inbound-channel-adapter id="jmsin" container="myContainer" destination-name="hello.queue" 
            		channel="stout">
            		<integration:poller>
            			<integration:interval-trigger interval="1"
            				time-unit="SECONDS" />
            		</integration:poller>
            	</jms:inbound-channel-adapter>
            It would be nice to have an attribute for message selector. I would like to confirm with you the correct behaviors of the two JMS channel adapters before I open the issue for the selector.

            Ron

            Comment


            • #7
              Thanks for pointing this out. The 'container' attribute should not even be present in the schema for the jms "inbound-channel-adapter" element. It is actually ignored completely (since that adapter polls directly and does not work with a MessageListener container under the covers in the first place). The 'container' should only be available on the "message-driven-channel-adapter".

              Can you please raise 2 issues:
              1) remove the "container" attribute from JMS inbound-channel-adapter
              2) add support for "selector" attribute on both inbound-channel-adapter and message-driven-channel-adapter

              The reason these should be separate is that #1 is a bug and #2 is an improvement.

              (and please link back to this forum post from the JIRA issue)

              Thank you.
              -Mark

              Comment


              • #8
                Dynamic Selectors

                Hi Mark,

                Just downloaded spring integration 2.0.0 Milestone 2 and I was glad to find that you guys have implemented the selector as part of the namespace.

                What I think would be beneficial is a way to add support for dynamic selectors. Image that I wanted a selector which selects a message from the queue after a given time X.

                AFAIK the only way to do this is to create a custom container and reference it as follows:

                Code:
                <jms:inbound-gateway id="jmsInboundGateway" 
                		container="myCustomListener"
                In my case the 'myCustomListener' extends the DefaultMessageListenerContainer, sets the CacheLevel to CACHE_SESSION and overrides the getMessageSelector() (which now will be called for each consumer).

                Would it be possible to add the functionality to reference a bean from the jms:inbound-gateway using some attribute so that dynamic selectors can be part of the default functionality?

                Regards,

                Mark

                Comment


                • #9
                  Hi guys - is there any response to the suggestion above (dynamic message selectors)?

                  This would also be very useful to me when we do the upgrade from version 1 to version 2.

                  Comment

                  Working...
                  X