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