|1B too for reasons Chris Barrow has stated.|
On 29 Jan 2013, at 18:00, John Harby <jharby@...
I agree with 1.B as well for the same reasons Chris gave.
On Tue, Jan 29, 2013 at 9:50 AM, John Archbold <jarchbol@...>
We vote for 1.B as well - JCA should not be required because, as
Chris Barrow says, there are plenty of uses of JMS outside of Java
On 1/28/2013 4:28 PM, Chris Barrow
My vote would be 1. B, because I do not believe JMS providers
should be forced to be part of the Java EE world. Messaging (and
Java) are useful outside of that world. As you put it yourself,
"This obligation would apply to all JMS vendors, including those
who are not otherwise interested in supporting Java EE. ". Why
would you want to impose JCA support on vendors who are not
interested in supporting Java EE?
On 1/28/2013 7:47 AM, Nigel Deakin wrote:
(Please read and respond to the two
questions below on this important issue - especially if you are
a JMS vendor)
Back in July 2011, one of our first decisions as an expert group
was to approve my proposal to make it mandatory for a JMS vendor
to provide a JCA resource adapter "to allow their JMS client to
be used from any Java EE application server".
In addition to that thread I also discussed it directly on the
phone with several expert group members including those who
represent JMS vendors)
You may remember that the reason for this requirement was to
make JMS providers more useful to users. Currently there is no
requirement for a JMS provider to work in a Java EE environment
This is what it now says in the JMS 2.0 public draft:
12. Resource Adapter
The Java EE Connector Architecture (JCA) specification defines a
standard architecture for connecting the Java EE platform to
enterprise information systems (EISs).
A JMS provider (whether it forms part of a Java EE application
server or not) is required to include a resource adapter which
connects to that JMS provider and which conforms to the Java EE
Connector Architecture specification and as further specified in
this chapter. Such a resource adapter is referred a "JMS
standard resource adapter".
The version of the Java EE Connector Architecture specification
which should be used is 1.7.
This chapter is not intended to prevent the creation and use of
additional resource adapters for connecting to a JMS provider
which do not conform to the specifications in this chapter.
However Java EE applications which use such resource adapters
may be less portable.
This text introduces a significant new requirement on the
developers of "standalone" JMS providers. I would therefore like
to be absolutely certain that the expert group and community is
in favour of it, and, if so, exactly what this requirement means
The wording above places an obligation on JMS vendors to
implement a JCA resource adapter. This obligation would apply to
all JMS vendors, including those who are not otherwise
interested in supporting Java EE. A JMS vendor who did not
implement a resource adapter could not describe their product as
supporting JMS 2.0.
*** Question 1: Do you agree with the existing wording of JMS
2.0, which says that "A JMS provider (whether it forms part of a
Java EE application server or not) is required to include a
If we are happy with this, then there is a further issue which
needs to be clarified. This is whether the resource adapter that
is provided should be able to work with *any* Java EE
application server. Although I think we did agree on this, the
current JMS 2.0 public draft does not explicitly require it,
which means that it would be valid for a vendor to provide a
resource adapter that only works with a Java EE application
server of their choice. Typically this would be the case if the
resource adapter, although implementing the required JCA API, is
dependent on the use of private APIs with the application
If your answer to question (1) was (A) then I'd like to ask a
*** Question 2: Do you think that the resource adapter should be
required to be "portable" and work with "any" Java EE 7
application server, or whether it need only work with a Java EE
7 resource adapter chosen by the vendor?
A: The resource adapter should be required to be "portable"
B: The resource adapter need only work with a Java EE 7 resource
adapter chosen by the vendor
This is an important issue because in addition to determining
how a resource adapter may be implemented it also determines
what kind of compliance tests are required. Choosing option (B)
means that the compliance tests can simply test the RA against
the Java EE reference implementation or a standalone JCA test
harness. Choosing option (A) means that the RA must be testing
in conjunction with a application server specified by the
Please express your views on both questions.
On 21/07/2011 14:56, Nigel Deakin wrote:
On 08/07/2011 17:01, Nigel Deakin wrote:
I'd like to start a disscussion about
this JIRA issue:
This issue is about the best way to support the portability
of JMS providers between Java EE application servers. At the
moment there is no (mandatory) API that allows this to be
done in a generic fashion which works with every such
All responses I have received on this topic so far have
supported making it mandatory for a JMS vendor to provide a
resource adapter to allow their JMS client to be used from any
Java EE application server. No-one has objected or argued
that this is an excessive burden on JMS vendors.
Some experts proposed making the existing Chapter 8 APi
mandatory API as in addition to this. This remains unresolved
and will be considered separately as JMS-SPEC_26.
I feel we might be approaching our first
decision-by-consensus! Unless anyone wants to jump in and
disagree, I will
consider this agreed in principle, and we can move on.
I will now
* draft some suitable modifications to the wording in the JMS
spec which I will ask you to review in due course
(actually trying to write the actual words may raise new
issues of detail).
* consult the Java EE spec lead about any wider implications
of adding this new dependency betweeen specs.
* add a note to this effect in the JIRA issue, and create a
subtask to cover the task (for me) of drafting the necessary
changes for what will be the JMS 2.0 Early Draft.