I think the annotation name "JMSListener" is too broad since JMS does
have other types of listener too (CompletionListener,
ExceptionListener). I would recommend going for "JMSMessageListener"
instead to disambiguate, or even "JMSOnMessage" since this is really
just about the method.
Chris Barrow
On 7/27/2015 10:51 AM, Rahman USTA wrote:
> Ahaa! Thank you Nigel;
>
> I agreed with your example codes. I did not know EJB 3.2 spec case
> about marker interface.
>
> About the interface names;
>
> @MessageDriven and @JMSListener, they seems nicely good. But,
> @MessageDriven may be @MessageDrivenBean, but I'm not sure. +Bean is
> long, but it says it is a Bean.
>
> Our JUG folks may say their ideas about JMS_SPEC-116 also.
>
> Thanks for explanation.
>
> If you want to get feedbacks or something about SPEC-116, please feel
> free to ping us.
>
>
>
> 2015-07-27 12:46 GMT+03:00 Nigel Deakin <nigel.deakin_at_oracle.com
> <mailto:nigel.deakin_at_oracle.com>>:
>
> 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/>
>
>
>
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta <http://www.kodcu.com/>