On 03/18/2013 10:19 PM, Wilson Tian wrote:
> Hi,
>
>> -----Original Message-----
>> From: Jesper Pedersen [mailto:jesper.pedersen_at_redhat.com]
>> 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.
>>
I wrote that too quickly - but Siva caught that :)
>
> I agree with Jesper that it should be explicit to readers of JCA SPEC that this new behavior is optional.
>
> Above suggestion from Jesper looks good.
>
> Another alternative is:
> add a new optional interface (the name may not be good, just for illustration)
> Public interface ReflectionAwareMessageEndpointFactory extends MessageEndpointFactory {
> public Class<?> getEndpointClass();
> }
> EJB spec may add text to mandate MDB container to implement this new ReflectionAwareMessageEndpointFactory interface.
> Other MEF implementations are free to either still implement the old MessageEndpointFactory (so indicate they do not support the new feature), or updated to implement the new ReflectionAwareMessageEndpointFactory interface.
> RA developers also can easily know whether the MEF implementation support this feature or not.
> All existing MEF implementations can still work and are not forced to upgrade.
> Another extra benefit is that with this new interface, endpoint developers can provide both static contract (methods defined in message listener interface) and dynamic contract (methods/annotations exposed by getEndpointClass() ) at same time to RA developers, and RA developers can use both of them, or choose one according their requirements freely. But I am not sure whether such complex use cases are useful or not.
> And thus eliminates the restriction that message listener must be empty.
>
I agree with you - in general we have too many requirements for use
cases that may not be supported by the resource adapter.
If we decide to go with JCA 2.0 for EE 8 lets take a deep look at that.
However, we have already added getActivationName() to MEF, so lets just
add this method too in order to get the spec out.
Best regards,
Jesper