Better support for generics and lambdas in JmsTemplate [SPR-10412]

[spring-projects-issues]

Philippe Marschall opened SPR-10412 and commented

I'm a bit unhappy with the API of JmsTemplate and MessageConverter and wanted to ask whether it would be possible to make some changes for Spring 4.0. Basically because MessageConverter is not generic #receiveAndConvert has to do a cast, and #convertAndSend is not type safe. Making MessageConverter generic itself doesn't fix the problem because there can only be one MessageConverter per JmsTemplate. It would have to be passed as an argument so that type propagation works correctly. As this likely will have to wait for Spring 4 which has Java 8 / lambdas as a topic MessageConverter should probably be split into two interfaces (one for sending, one for receiving).

Maybe the interfaces should be tagged with java.lang.FunctionalInterface but that would have to be done over the whole code base.

---

Issue Links:

• Support org.springframework.messaging.Message as an alternative to MessageCreator in the JMS support [SPR-11772] #16394 Support org.springframework.messaging.Message as an alternative to MessageCreator in the JMS support

0 votes, 6 watchers

[spring-projects-issues]

Philippe Marschall commented

This is the pull request against the master (4.0) branch:
#266

[spring-projects-issues]

Stéphane Nicoll commented

We had an extensive look to your patch and we decided not to apply it for several reasons.

JmsTemplate has already a significant number of methods and adding a support for generics is making it quite worse actually.

For convertAndSend it looks like a variant of MessageCreator. You might say that you can get a type checking that the converter is able to handle your payload but in practice we don't really see that as a problem.

For the receiving part, most receiving operations should go asynchronously and Spring has an excellent support for making sure you get the proper object injected in your endpoint.

[spring-projects-issues]

Philippe Marschall commented

JmsTemplate has already a significant number of methods and adding a support for generics is making it quite worse actually.

JmsTemplate has a fraction of the number of methods of JdbcTemplate

For the receiving part, most receiving operations should go asynchronously and Spring has an excellent support for making sure you get the proper object injected in your endpoint.

That requires EE 7. That's years away.

[spring-projects-issues]

Stéphane Nicoll commented

What requires EE7 exactly?

[spring-projects-issues]

Philippe Marschall commented

Going asynchronously with Spring. DefaultMessageListenerContainer and friends create threads and the only portable and supported way of doing this is EE 7. The only workarounds I know of are the CommonJ work managers for WebSphere and WebLogic.

[spring-projects-issues]

Juergen Hoeller commented

Philippe, while it's technically true that standardized portable thread creation (JSR-236) is an EE 7+ feature, lots of people have been doing specific thread creation arrangements on Spring ever since 2007, in particular also in EE environments, and usually with great success. There is CommonJ on WebLogic and WebSphere as you mentioned, officially supported by Oracle and IBM; there are embedded thread pools or JCA-provided thread pools on JBoss; and embedded local thread pools work great on Tomcat, Jetty and others as well.

We strongly recommend those options in order to arrive at a modern processing architecture now - in 2014 (or even back in 2007) and not in 2016 or whenever EE 7 will become mainstream. That sort of effect has been with us for all EE generations, but well, it is particularly important with EE 7 which - as a platform - faces depressingly slow industry adoption in such critical times. And then just compare all the recent reactive programming initiatives, from Akka and vert.x to Reactor, with asynchronous processing at the heart of it all...

That said, let's discuss the synchronous receive story a bit: With JmsTemplate's standard receive methods, you'll get a JMS Message returned that you can then extract the body from. Are you concerned with exception handling there, or would you simply prefer more convenience for such code paths? I could imagine receive variants with a MessageResultProcessor callback along those lines... if there is a compelling enough story here. In any case, MessageConverter doesn't seem to be quite right for such per-operation callbacks.

Juergen

[spring-projects-issues]

Philippe Marschall commented

The JCA-provided thread pools on JBoss are only valid within the context of a JCA resouce adapter. Using them outside of a JCA resouce adapter is invalid. You'd have to deploy your application as a RAR to be on the safe side. JBoss AS 7+ no longer exposes the JCA work manager through JNDI so DefaultMessageListenerContainer no longer works on JBoss AS 7+. Either people haven't migrated yet, use something else or things appear to work by chance. Se also this thread:
https://community.jboss.org/thread/169380?start=15&tstart=0#794662

The recent reactive programming initiatives feel a lot like the modular/OSGi programming initiatives several years ago.

[spring-projects-issues]

Juergen Hoeller commented

Point taken about the JCA resource adapters on JBoss; however, there's also the option of using locally embedded thread pools (such as Spring's ThreadPoolTaskExecutor) which is common on JBoss as well and apparently also alright from a JBoss perspective (according to that JBoss forum thread). So to the best of my knowledge, Spring's DefaultMessageListenerContainer does work fine on JBoss - in combination with a locally managed thread pool, even on JBoss AS 7.

In any case, I don't think that the non-availability of JSR-236 is a reason to avoid asynchronous message listening. One could blame EE for not actually adopting JSR-236 earlier (it's been considered even for EE 5 back then), but well, it is what it is. A degree of pragmatism is needed on all sides here: on our side, on the server vendors' side (and even IBM is pretty pragmatic about the specific problem at hand here), and - please - also on the users' side. Otherwise we're all stuck.

That said, for this specific JIRA issue, I'm more interested in your JmsTemplate style interaction patterns. See my comment above - would a MessageResultProcessor argument on JmsTemplate receive methods be useful for your purposes? To what degree is it just syntactical, i.e. where do you see the particular advantage over a regular receive call and custom extraction from the JMS Message itself? Is it exception handling, is it message casting, is it reusable extraction logic?

Juergen

[spring-projects-issues]

Philippe Marschall commented

It's mostly a convenience and type safety (casting) issue. Having to cast everywhere makes the JMS code feel different from the rest of the code base where casts can be mostly avoided. Mainly we would like to be the JmsTemplate programming model more like the JdbcTemplate programming model. eg.

send:
taking a typed object (and a destination name) and a stateless function object mapping the former type to a message
ideally the function object would not have to create the right type of message through a session but get it passed in as an argument (much like #update(String, PreparedStatementSetter) does not have to create a prepared statement)

receive:
taking a stateless object (and a destination name) that converts from a message subtype (eg. TextMessage) of a specific type to an object of another type (and a destination name)
receive then returning an object of the later type
some error handling would have to be defined in the message is not of the expected message subtype

Having the converters being functional interfaces would be really welcome.

To sum up lambdas and generics work really well with with JdbcTemplate. We feel JmsTemplate is lacking by comparison. JdbcTemplate has a place even in a world with ORMs, Spring Data, …. We feel the same is true for JmsTemplate.

We're trying to be pragmatic but we have often enough experienced that going directly against vendor recommendations backfires when upgrading vendor software resulting in long and painful migrations.