1B too for reasons Chris Barrow has stated.
thanks,
Rob
On 29 Jan 2013, at 18:00, John Harby <jharby_at_gmail.com> wrote:
> 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
>>>>
>>>>
>>>>
>>
>>
>
>