Hi David
My reservations earlier were based on the earlier proposal, and Marina
would have shared them with you.
I am still trying to understand the new proposal better. So, please
correct me if my assumptions below are incorrect.
- If I understand the new proposal correctly, you would like the RA to
have the ability to cast the endpoint proxy to the bean class. Why would
the RA need the proxy to be assignable to the bean class?
- I also understand that the new proposal and the example, has broken the
MessageListener interface into multiple fine-grained annotations that
could then be placed on the MDB and then driven during message delivery.
Is this understanding right? We now have the ActivationSpec not just
responsible for configuration of the Message endpoint, but also define the
specifics on how the message delivery is performed.
- Adding in a beanClass property in ActivationSpec now is a backward
incompatible change.
- The resource adapter may not portably have permissions for Reflection.
I would also like to request the other Connector EG members weigh in.
Thanks
--Siva.
On Tuesday 05 February 2013 06:54 AM, David Blevins wrote:
> Drilling in to be as specific as possible. The activation config
> property note is entirely in the EJB spec, so we're good in that
> regard.
>
> The one, nice-to-have, note for the Connector specification would be
> an update to section 13.5:
>
> "the endpoint instance supplied by the createEndPoint method call is
> a proxy which implements the endpoint message listener type [and is
> assignable to the bean class]"
>
> In case there was a misunderstanding it was never proposed that said
> proxy would not implement the message listener interface, simply that
> in addition the proxy would be castable to the bean class similar to
> @LocalBean. The term "no-interface-view" has been used to describe
> this kind of proxy, which I think has lead to some confusion. I've
> never liked the term "no-interface-view" even when we were using it in
> EJB 3.1 and am actually the one who proposed @LocalBean. Reason being
> is the bean may in fact have interfaces as is the case here and is
> easily the case in EJB session beans. Having no interfaces is simply
> one way to turn this on, the other is via annotation. Our plan is to
> turn this on for MDBs as well.
>
>
> -David
>
> On Mon, Feb 4, 2013 at 3:43 PM, David Blevins <david.blevins_at_gmail.com> wrote:
>> Timeline issues aside, what is the objection to EJB_SPEC-60?
>>
>> If it is a matter of how useful it is, the EJB EG is very on board and this is our third most popular issue of EJB 3.2.
>>
>> If it is a matter of size of change, no actual change to the JCA API need be changed. Two spec notes would be nice, but are not strictly required as they are actions taken by the EJB Container. These are:
>>
>> - A mention that the MDB Container will be offering the inbound connector a MessageEndpoint that is akin to a no-interface view.
>> - A mention that the MDB Container will inject the bean class into the activation config, should the spec contain a 'beanClass' property.
>>
>>
>> -David
>>