Annotation-driven JMS endpoints [SPR-9882]

[spring-projects-issues]

Juergen Hoeller opened SPR-9882 and commented

@JmsListener(destination="myQueue", selector="...")
public void handleMessage(String payload)

Activated through jms:annotation-driven, possibly underneath a jms:listener-container element. Creating and registering DefaultMessageListenerContainer beans underneath the covers, just like for jms:listener entries.

---

Issue Links:

• Support JMS 2.0 (JSR-343) [SPR-8197] #12846 Support JMS 2.0 (JSR-343)
• Applying the spring-messaging module to JMS [SPR-10873] #15500 Applying the spring-messaging module to JMS
• Support JMS 2.0's shared consumers in message listener containers [SPR-11969] #16585 Support JMS 2.0's shared consumers in message listener containers
• JmsListener/ScheduledAnnotationBeanPostProcessor should use SmartInitializingSingleton instead of ContextRefreshedEvent [SPR-12039] #16655 JmsListener/ScheduledAnnotationBeanPostProcessor should use SmartInitializingSingleton instead of ContextRefreshedEvent
• Backward compatibility: initDefaultStrategies() is no longer invoked on subclasses of "MessageListenerAdapter" [SPR-15043] #19609 Backward compatibility: initDefaultStrategies() is no longer invoked on subclasses of "MessageListenerAdapter"

Referenced from: commits 6aa16b7, 713dd60, 50c5cc0, a9100c4

1 votes, 5 watchers

[spring-projects-issues]

Stéphane Nicoll commented

I've started to brainstorm on this topic. Juergen Hoeller would you mind to review/comment this? Thanks!

[spring-projects-issues]

Juergen Hoeller commented

Stéphane, in a next iteration, we should starting considering #15500: that is, support for spring-messaging API types as alternative method arguments, next to native JMS Message types and plain message body values. Basically, that's @MessageMapping and the argument types listed there. It'd be nice to support those for XML jms:listener methods as well, but it's particularly interesting for annotated listener methods, leading to an endpoint implementation style that can be largely consistent across JMS, AMQP and STOMP.

http://docs.spring.io/spring/docs/4.0.0.RELEASE/javadoc-api/org/springframework/messaging/handler/annotation/MessageMapping.html

There's even the question whether @MessageMapping should be the only endpoint marker supported, with additional JMS semantics somehow rolled into extra attributes or expressed through an additional annotation (to be combined with @MessageMapping, similar to qualifier annotations used with @Autowired). The disadvantage is that we'd lose the immediate alignment with our jms:listener style; for that reason, it may be worth supporting two endpoint mapping annotations here. Even then, that would ideally only influence how we build our mappings; method argument resolution and general listener invocation semantics could still be unified for all JMS endpoints.

So those are essentially related but ideally independent feature concerns:

• support for annotated JMS listener methods, as suggested above based on @JmsListener or the like, and as currently prototyped
• support for @MessageMapping as alternative to @JmsListener, or even exclusively supporting it as the only mapping annotation
• support for spring-messaging's header and payload conversion style in MessageListenerAdapter, for any JMS listener method

Juergen

[spring-projects-issues]

Stéphane Nicoll commented

Sure that make sense. I just pushed a prototype for this particular issue. Speaking of which, the message listener part is a big todo because at some point we should indeed fallback on @MessageMapping and the like. I'll have a look to that next.

[spring-projects-issues]

Gary Russell commented

I wonder if we should consider @MessageListener instead of @JmsListener - that way, the same listener could be plugged into a JMS or AMQP container/listener adapter.

We could allow various method signatures, such as...

@MessageListener
public void onMessage(SomePojo pojo) {}

@MessageListener
public void onMessage(o.s.m.Message<?> message) {}

@MessageListener
public void onMessage(@Payload SomePojo pojo, @Headers Map<String, Object> headers) {}

@MessageListener
public void onMessage(@Payload SomePojo pojo, @Header("priority") Integer priority) {}

etc.

I don't believe we'd have to bring AMQP into core, we'd just have Spring-AMQP use the core annotation.

[spring-projects-issues]

Juergen Hoeller commented

Gary, this is very much in line with what I've been hinting at above, with spring-messaging's @MessageMapping as the common annotation and the argument types defined in its javadoc as common arguments. This what we're supporting for STOMP endpoints already, so we're trying to make this work for JMS as well. The consideration of a dedicated @JmsListener annotation is just for JMS-specific metadata, next to @MessageMapping which is focused on a String-based destination mapping. We might not need @JmsListener at all, with @MessageMapping as the central marker and additional annotations qualifying a mapping further (e.g. for JMS Session modes through an @JmsSession annotation).

I completely agree that the common model should be usable for AMQP, with Spring AMQP simply supporting the same common annotations and argument types. Most of what we need is there in Spring Framework 4.0's spring-messaging module already; we just need to extend its reach to straightforward use with JMS (here) and AMQP (in Spring AMQP).

Juergen

[spring-projects-issues]

Stéphane Nicoll commented

@JmsListener annotated methods can be defined with flexible method parameters, see @JmsListener

[spring-projects-issues]

Stéphane Nicoll commented

A first iteration on this issue lead to this proposal. There are still a few design issue that should be sorted but most of the logic is there

[spring-projects-issues]

Stéphane Nicoll commented

This has been merged to master. Note that 713dd60fa7484 also fixes #15500.

See the commit message for more information.