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>:
> 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/>