Over-zealous containerType restrictions in simplified API

[glassfishrobot]

The simplified API implementation contains code to enforce the JMS restrictions on calling certain methods in a Java EE web or EJB container.

This includes com.sun.messaging.jmq.jmsclient.JMSContextImpl and com.sun.messaging.jmq.jmsclient.XAJMSContextImpl, which contain checks on the methods createContext, setClientID, setMessageListener amongst others.

These tests use a method getContainerType on the connection factory to determine what kind of environment the method is being called in.

In general, this returns ContainerType.JavaSE except for com.sun.messaging.jmq.jmsclient.XAConnectionFactory#getContainerType() which uses JNDI is used to determine whether the code is running in a Java EE web or EJB container.

This is a bit inconsistent but that's not the issue here.

The problem is that these classes shouldn't really be enforcing these restrictions at all. In a Java EE environment, these classes are intended to be wrapped by a resource adapter (or by other wrappers provided by the application server). They aren't intended to be used directly by applications. Responsibility for enforcing these restrictions lies with the resource adapter or wrapper.

However, the fact that these classes do enforce these restrictions prevents the use of methods such as setMessageListener by a resource adapter or by app server wrapper classes, despite this being perfectly legal. The prohibition on calling certain methods applies to applications, not to app server integration code (though perhaps the spec could be clearer).

Enforcing these restrictions at this level may cause difficulties for app server and resource adapter vendors. This applies particularly to the restrictions enforced by XAJMSContextImpl, which, after all, is expressly intended for use by app server and resource adapter vendors only.

So, it is hereby proposed to remove the enforcement of these restrictions from the MQ client.

To conform to the JMS specification, this means extra checks may be needed at resource adapter level, such as in JMSRA.

Affected Versions

[5.1.1]

[glassfishrobot]

@glassfishrobot Commented
Reported by @nigeldeakin

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA MQ-365

[glassfishrobot]

@nigeldeakin Commented
This still looks like a valid issue, though since JMS 2.0 has now been released for a couple of years now and no-one has encountered this issue in practice, I think the priority for fixing this is fairly low. So reducing the priority from major to minor.

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/openmq/issues/365
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @nigeldeakin