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.
Fred, Byung-Woo - what are your thoughts ?
>> 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.
And why would it only apply to the MDB case ? All endpoint types should
benefit of this new method.
Best regards,
Jesper