Thank you Nigel. Yes, I've already joined the list.
2015-07-28 12:02 GMT+03:00 Nigel Deakin <nigel.deakin_at_oracle.com>:
> Rahman,
>
> On 27/07/2015 18:51, 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.
>>
>
> @javax.ejb.MessageDriven is the existing *annotation* to specify a MDB.
> Since this is still a MDB, this is still needed.
>
> javax.jms.JMSMessageDrivenBean is the proposed new marker *interface* to
> specify a new-style *JMS* MDB. As I explained, I'm hoping this will not be
> needed. I agree that it would be confusing and verbose to require both.
>
>
>> Our JUG folks may say their ideas about JMS_SPEC-116 also.
>>
>
> Great. Please invite them to look at
> https://java.net/projects/jms-spec/pages/JMSListener2
>
>
>> Thanks for explanation.
>>
>> If you want to get feedbacks or something about SPEC-116, please feel
>> free to ping us.
>>
>>
> Are you signed up to users_at_jms-spec.java.net ? That will ensure you don't
> miss anything.
>
> Nigel
>
>
>
>> 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/>
>>
>
--
Rahman USTA
Istanbul JUG
https://github.com/rahmanusta <http://www.kodcu.com/>