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