Hi Rahman, thanks for your comments.
I have written up some more detailed proposals for improving MDBs (in direct response to this JIRA issue) at
https://java.net/projects/jms-spec/pages/JMSListener2 .
I think I am in agreement with everything you say, and if you take a look at those more detailed proposals I hope you
will see this.
I am currently proposing that
(1) The MDB must implement a new marker interface JMSMessageDrivenBean
(2) The callback method must be annotated with @JMSListener
@MessageDriven
public class MyMessageBean implements JMSMessageDrivenBean {
@JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
public void processTrade(TextMessage tradeMessage){
...
}
}
I agree with you that the need to implement a marker interface is undesirable. However it is needed to work around a
restriction in the EJB 3.2 specification. Essentially, EJB 3.2 only allows callback methods that are not defined using a
listener interface such as javax.jms.MessageListener if the MDB implements a no-methods marker interface.
I'm hoping to get the EJB specification to remove the need to implement a no-methods marker interface. If this is done
then MDB can look like:
@MessageDriven
public class MyMessageBean {
@JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
public void processTrade(TextMessage tradeMessage){
...
}
}
Nigel
On 25/07/2015 13:23, Rahman USTA wrote:
> Hello, I'm Rahman from Istanbul JUG;
>
> I have read JMS_SPEC-116 <https://java.net/jira/browse/JMS_SPEC-116>, in Description, and I want to give some
> feedbacks, suggestion 1)
>
> 1. Introduce a new interface "javax.jms.JMSMessageEndpoint" (or similar name) that can be used as a marker interface
> required by MessageEndpointFactory.getEndpointClass(). It shall have no methods, not extend any other interface but
> simply exist to be a marker that the given class will have its public methods exposed as potential targets for messages
> received by the RA.
>
> There is a suggested JMSMessageEndpoint interface to mark class a JMS message endpoint. In Java EE practice, I'm seeing
> annotation markers are more used than marker interface. For example JSR 356 WebSocket API has @ServerEndpoint
> annotation. Like that, JMS might has @JMSMessageEndpoint annotation instead of a marker interface.
>
> Suggestion 3)
>
> 3. Currently, the onMessage method is defined by looking for a method named "onMessage" that takes a "Message" object as
> an argument. This algorithm should be changed to also look for any instance of "JMSMessageEndpoint", find any method
> that is annotated as XXX (whatever is defined in 2) as a possible target, then depending on there being a match between
> that takes anything that derives from "Message" and only pass appropriate messages to it.
>
> As a suggested @JMSMessageEndpoint annotation, message receivers may be declared by annotation for example @OnMessage.
>
> Also, @OnMessage annotation might have some properties to customize Messge listener method.
>
> What do you think for that?
>
> Thanks.
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta <http://www.kodcu.com/>