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.
>
> Best regards,
> Jesper
>
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 don't have strong preference and am fine to either of suggestions.
Thanks
Wilson