You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to our delayed GA in March 2017, along with JDK 9's GA delay, we should re-consider whether to raise our JMS baseline to 2.0+.
The hard references to the JMS 1.1 API in TomEE 1.7, JBoss EAP 6.4, WebSphere 8.x Classic, WebLogic 12.1.3 make this a tough decision. At a minimum, JMS 2.0 / EE 7 based variants of those would have to be available: However, at the end of 2015, TomEE 7, JBoss EAP 7 and WebSphere 9 are just in alpha, and WebLogic 12.2.1 is out for a few weeks.
Let's see where we are by the end of 2016 and evaluate continued need for JMS 1.1 providers then. If feasible, we should aim to go JMS 2.0+ in Spring 5.0+ since there's always Spring 4.3 as a fallback, continuing with JMS 1.1+ support for its entire extended support life. And let's not forget that JMS 1.1 dates back to 2002; it is about time to get rid of it.
Finally, since this is just about the JMS API anyway, JMS 1.1 providers can even still work with Spring 5, as long as the JMS 2.0 API is present on the classpath. There is no need to adapt our JMS invocation patterns, that is, no need to invoke new JMS 2.0 methods in our regular template/listener call paths. This ticket is primarily about allowing us to compile against JMS 2.0, avoiding the use of reflection for optional calls to new JMS 2.0 methods.
The spring-jms module has been upgraded to require JMS 2.0, including an upgrade to JCA 1.7 (as supported in our JMS JCA container mode but also generally in the spring-tx module).
Juergen Hoeller opened SPR-13793 and commented
Due to our delayed GA in March 2017, along with JDK 9's GA delay, we should re-consider whether to raise our JMS baseline to 2.0+.
The hard references to the JMS 1.1 API in TomEE 1.7, JBoss EAP 6.4, WebSphere 8.x Classic, WebLogic 12.1.3 make this a tough decision. At a minimum, JMS 2.0 / EE 7 based variants of those would have to be available: However, at the end of 2015, TomEE 7, JBoss EAP 7 and WebSphere 9 are just in alpha, and WebLogic 12.2.1 is out for a few weeks.
Let's see where we are by the end of 2016 and evaluate continued need for JMS 1.1 providers then. If feasible, we should aim to go JMS 2.0+ in Spring 5.0+ since there's always Spring 4.3 as a fallback, continuing with JMS 1.1+ support for its entire extended support life. And let's not forget that JMS 1.1 dates back to 2002; it is about time to get rid of it.
Finally, since this is just about the JMS API anyway, JMS 1.1 providers can even still work with Spring 5, as long as the JMS 2.0 API is present on the classpath. There is no need to adapt our JMS invocation patterns, that is, no need to invoke new JMS 2.0 methods in our regular template/listener call paths. This ticket is primarily about allowing us to compile against JMS 2.0, avoiding the use of reflection for optional calls to new JMS 2.0 methods.
Issue Links:
Referenced from: commits 355c6f0
The text was updated successfully, but these errors were encountered: