users@connector-spec.java.net

[connector-spec-users] Re: Fwd: [jsr322-experts] Re: ACTION (by Mar 18/Mon): Please review changes to the connector spec to handle proposed MDB improvements

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Mon, 18 Mar 2013 11:28:47 -0700

I don't care. The Connector EG can decide.

Marina Vatkina wrote on 3/18/13 10:44 AM:
> I don't have strong preferences, and if the JCA experts feel that EndpointClass
> is not ambiguous, let it be that.
>
> -marina
>
> On 3/18/13 8:14 AM, Sivakumar Thyagarajan wrote:
>> Hi Bill/Linda/Marina/David/Jeremy
>>
>> What do you think about Jesper's comments below? Jesper's comment is that the
>> name "Endpoint" in "getEndpointClass" when used in a Connectors API class
>> (MessageEndpointFactory) and used by a RA developer means the "Bean class"
>> (the message endpoint - the MDB) and is unambiguous. "Bean" class OTOH, is
>> ambiguous for a RA developer.
>>
>> Can we go back to "getEndpointClass()" since the predominant audience for the
>> API are RA developers?
>>
>> Jeremy/David: would you agree?
>>
>> Thanks
>> --Siva.
>>
>>
>> -------- Original Message --------
>> Subject: [jsr322-experts] Re: ACTION (by Mar 18/Mon): Please review changes to
>> the connector spec to handle proposed MDB improvements
>> Date: Mon, 18 Mar 2013 10:58:43 -0400
>> From: Jesper Pedersen <jesper.pedersen_at_redhat.com>
>> Reply-To: jsr322-experts_at_connector-spec.java.net
>> Organization: JBoss, by Red Hat
>> To: jsr322-experts_at_connector-spec.java.net
>>
>> Hi,
>>
>> On 03/18/2013 10:50 AM, Sivakumar Thyagarajan wrote:
>>>> My feedback still applies - there is no concept of a "bean" in JCA.
>>>>
>>>> Any discussion on the JCA API should take place on this mailing list.
>>>
>>> I agree that we should have discussed the name earlier. It was my
>>> mistake not to copy this list. Sorry about that.
>>>
>>> Do you see that the name getEndpointClass is ambiguous? Are there are
>>> better method names that you could suggest that doesn't use the word
>>> /Bean/?
>>>
>>
>> No, I think that getEndpointClass() is a good name, as the resource
>> adapter developer never interacts with the proxy - well, at least he/she
>> doesn't think that.
>>
>> In the JCA spec we use "endpoint" and "proxy of the endpoint".
>>
>> So in that case getEndpointClass() makes sense.
>>
>> The only other alternative is to move the method to the MessageEndpoint
>> interface, and come up with a new name that we can explain in that context.
>>
>>>> Since the message listener interface is empty we need to expand the
>>>> description in 13.5 otherwise the endpoint vendor will miss the fact
>>>> that they need to proxy the endpoint business methods in their proxy. We
>>>> can't depend on text in other specifications for such an important
>>>> change.
>>>
>>> Ok, I see what you mean here. However it must be noted that our intent
>>> is to make it completely optional for non-MDB message endpoint factories
>>> to create a proxy with all message listener methods of the non-MDB. We
>>> have never stated any additional (beyond those stated in the Chapter 13
>>> around Message Endpoints) requirements on non-MDB message endpoints in
>>> the spec. So, I would like to keep it that way.
>>>
>>> We can add a line in our spec, that for the case of MDBs, we require the
>>> MEF implementation to follow the requirements in the EJB spec (that
>>> requires the MessageEndpoint proxy to implement message listener methods
>>> from the MDB class provided by the application developer)
>>>
>>>> And why would it only apply to the MDB case ? All endpoint types should
>>>> benefit of this new method.
>>>
>>> They should benefit (through the verbiage in the current spec). What we
>>> don't want to do is require them to proxy all their non-MLI endpoint
>>> methods. Does this (important IMHO) distinction help?
>>>
>>
>> If the feature is optional then return value of getEndpointClass() must
>> reflect that.
>>
>> Eg.
>>
>> A return value of <code>null</code> indicates that the
>> MessageEndpointFactory doesn't implement the business methods of
>> underlying MessageEndpoint class.
>>
>> Best regards,
>> Jesper
>>
>>
>>
>