On a web application using Spring 5.2.x the following is showing up in the log files:

 java.lang.NullPointerException
    at org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:208) ~[spring-jms-5.2.20.RELEASE.jar:5.2.20.RELEASE]
    at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:495) ~[spring-jms-5.2.20.RELEASE.jar:5.2.20.RELEASE]
    at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:576) ~[spring-jms-5.2.20.RELEASE.jar:5.2.20.RELEASE]
    at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:680) ~[spring-jms-5.2.20.RELEASE.jar:5.2.20.RELEASE]
    at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:668) ~[spring-jms-5.2.20.RELEASE.jar:5.2.20.RELEASE]

The code that explains what is going on at a high level is JmsTemplate::execute. That code shows that the connection created by the assigned connection factory returned a null connection instead of throwing JMSException. The API contract for JmsTemplate::execute states "throws JmsException if there is any problem" but that is not true if the connection factory returned null instead of throwing JMSException.

While the root cause is the broken ConnectionFactory implementation, I think this code could be improved a bit by:

  1. Patch JmsAccessor::createConnection to throw JMSException if a connection factory returns a null connection. The error message should contain the class name of the factory that is not complying with the API spec.
  2. Patch JmsAccessor::createSession throw JMSException if the connection parameter is null.
  3. A more conservative alternative to number 1 would be to patch JmsTemplate.execute to simply check the conToClose prior to creating a session.

This issue is a low priority as these errors only occur during a shutdown of the application so impact of this issue is trivial. It just produces a confusing message in the logs.

Comment From: jhoeller

We have such defensive null-checking code for DataSource.getConnection access in spring-jdbc, so it should be feasible to do the same in spring-jms.

Comment From: jhoeller

Coming to 6.0.4 first, to be backported to 5.3.25 in a second step.

Comment From: jmehrens

FYI, here is an example offender that is now correctly handled by this patch:

https://github.com/apache/activemq/blob/30114aa86df726a37f9cf972e07646b11732e3c9/activemq-jms-pool/src/main/java/org/apache/activemq/jms/pool/PooledConnectionFactory.java#L217