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
>
>
>