On Tuesday 19 March 2013 05:14 PM, Sivakumar Thyagarajan wrote:
> Hi everyone
>
> On Tuesday 19 March 2013 12:18 AM, Jeremy Bauer wrote:
>> My other suggestion is "getEndpointBeanClass" which also hints at the
>> possibility of getting a proxied class. Given that there is no concept
>> of bean in JCA, that name would be foreign as well. I'm fine with the
>> original method name.
>
> Ok, thanks Jeremy, Marina, Bill and Wilson for your comments.
>
> The consensus is that we will go with Jesper's suggestion of using the
> old name "getEndpointBeanClass" and add the following to the javadoc
Sorry -- the phrase above should have been 'using the old name
"getEndpointClass"'.
Thanks
--Siva.
> --- snippet ---
> A return value of <code>null</code> indicates that the
> MessageEndpoint doesn't implement the business methods of
> underlying message endpoint class.
> --- snippet ---
>
> I will send the updated spec and javadoc in a few hours.
>
> Thanks
> --Siva.
>
>>
>> -Jeremy
>>
>>
>>
>> From: Marina Vatkina <marina.vatkina_at_oracle.com>
>> To: Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>,
>> Cc: Bill Shannon <bill.shannon_at_oracle.com>, Linda DeMichiel
>> <linda.demichiel_at_oracle.com>, David Blevins <david.blevins_at_gmail.com>,
>> Jeremy Bauer/Rochester/IBM_at_IBMUS, users_at_connector-spec.java.net,
>> jsr322-experts_at_connector-spec.java.net
>> Date: 03/18/2013 12:45 PM
>> Subject: Re: Fwd: [jsr322-experts] Re: ACTION (by Mar 18/Mon): Please
>> review changes to the connector spec to handle proposed MDB improvements
>> ------------------------------------------------------------------------
>>
>>
>>
>> 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
>> >
>> >
>> >
>>
>>
>