Results 1 to 9 of 9

Thread: JMS Message Selectors

  1. #1
    Join Date
    Feb 2008
    Posts
    13

    Default 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. #2
    Join Date
    Apr 2008
    Posts
    3

    Default

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

  3. #3
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,853

    Default

    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

  4. #4
    Join Date
    May 2009
    Posts
    7

    Default

    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

  5. #5
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,853

    Default

    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.

  6. #6
    Join Date
    May 2009
    Posts
    7

    Default

    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

  7. #7
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,853

    Default

    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

  8. #8
    Join Date
    Jan 2010
    Posts
    7

    Default 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

  9. #9
    Join Date
    Aug 2009
    Posts
    9

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •