Hi Jesper
Thanks for your comments. See inline.
On Monday 18 March 2013 07:12 PM, Jesper Pedersen wrote:
> Hi Siva,
>
> On 03/17/2013 08:53 AM, Sivakumar Thyagarajan wrote:
>>> Why is it called "getBeanClass()" now ? I don't like that - it should
>>> be "getEndpointClass()".
>>
>> It was pointed in a feedback in the EJB EG that "the getEndpointClass
>> method name should be changed to emphasize that this method is not
>> returning the endpointinterface or the endpoint implementation class,
>> but some class that backs the endpoint".
>>
>> For instance getEndpointClass may be read as
>> MEF.createEndpoint().getClass(), which is not the intent of the method.
>> We basically want the beanClass (in the case of MDBs) of the
>> MessageEndpoint created by the MessageEndpointFactory provided to the RA
>> through this method. For non-MDB MEFs, they should return the class of
>> the component that the developer wrote.
>>
>> Since other alternative method names suggested were not immediately
>> unambiguously obvious which class was referred to, we felt that we can
>> choose a method name that works for most of us. The spec and the
>> javadocs would make it cleared to the user.
>>
>>
>>> We don't have a concept of a "bean" in JCA - but we have an
>>> endpoint.
>>>
>
> 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/?
> Fred, Byung-Woo - what are your thoughts ?
Sure, let us hear from others too.
>>> Section 13.5 is missing the part where the proxy implements all
>>> public business methods of the actual endpoint. Otherwise reflection
>>> won't work on the returned MessageEndpoint from the
>>> MessageEndpointFactory.
>>
>> 13.5 says:
>> -- quote --
>>> Note that the endpoint instance supplied by the createEndpoint
>>> method call is a proxy which implements the endpoint message listener
>>> type and the MessageEndpoint interface and it is not the actual
>>> endpoint.
>> --quote --
>>
>> The above doesn't prohibit the case where the proxy implements all
>> message listener methods of the MDB, so I think it's ok as is. It just
>> describes a minimum requirement of the proxy, which will remain true.
>>
>> Do you think adding it would be more clearer. Even if we add it we can
>> only say that in the case of MDBs, we would want that behaviour, and
>> that is already covered in the EJB/MDB spec that we discussed earlier at
>> http://java.net/projects/connector-spec/lists/users/archive/2013-03/message/26
>>
>
> A MDB is just only one implementation of an endpoint.
>
> 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?
Thanks
--Siva.
> Best regards,
> Jesper
>