I agree with 1.B as well for the same reasons Chris gave.
Thanks,
John Harby
On Tue, Jan 29, 2013 at 9:50 AM, John Archbold <jarchbol_at_tibco.com> wrote:
> Hi Nigel,
>
> 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 EE.
>
> Thanks,
> John
>
> On 1/28/2013 4:28 PM, Chris Barrow wrote:
>
> Hi Nigel,
>
> 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?
>
> thanks,
> Chris
>
> 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".
>
> (See
> http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2011-07/message/42.
> 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 at all.
>
>
> 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 in practice.
>
> 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 resource adapter".
>
> A: Yes
>
> B: No
>
> 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 server.
>
> If your answer to question (1) was (A) then I'd like to ask a further
> question.
>
> *** 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 vendor.
>
> Please express your views on both questions.
>
> Thanks,
>
> Nigel
>
>
> 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:
> http://java.net/jira/browse/JMS_SPEC-25
>
> 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
> combination.
>
>
> All responses I have received on this topic so far have supported making
> 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. 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.
>
> Thanks,
>
> Nigel
>
>
>
>
>
>
>