I also logged this this JIRA issue:
http://java.net/jira/browse/JMS_SPEC-26
Essentially, this stated that Chapter 8 of the JMS 1.1 specification, "JMS Application Server Facilities", defines an
API for use by application servers. It has two parts: API to allow concurrent processing of a subscription's messages,
and API to support distributed (XA) transactions. This API is optional and has no compliance tests.
Should this API be made mandatory, like the rest of the JMS spec, or should it be formally pruned from the spec?
This really depends on the outcome of JMS_SPEC-25 (Standardise the interface between a JMS provider and a Java EE
application server). If it is decided that the interface between a JMS provider and a Java EE application server should
use these interfaces (rather than the Java EE Connector API) then clearly they should become mandatory.
However, irrespective of the outcome of JMS_SPEC-25 it may be beneficial to keep this API and make it mandatory since
that would
1. allow the creation of a generic JMS resource adapter that can work with any JMS 2.0 implementation, and
2. allow the creation of non-Java EE frameworks that provide services such as XA transactions and async delivery to
multiple consumers, but which don't support the Java EE Connector Architecture
However these potential benefits need to be offset against the additional burden this may place on JMS vendors.
Note that if it is decided that these interfaces are _not_ needed, they would not be deleted from the spec but remain in
their current optional state, in accordance with chapter EE.6.1.3 "Pruned Java Technologies" of the Java EE 6
specification.
So effectively the choice is:
1. Make them mandatory
2. Do nothing (so they remain an optional part of the spec)
3. Formally prune them by making an explicit statement to that effect, whilst leaving them in the spec.
I suggest we focus our discussion on the other thread initially, and come back to this when we've come to a consensus there.
Nigel