Werner,
On 11/09/2015 09:30, Werner Keil wrote:
> Nigel,
>
> Thanks for outlining those options.
>
> I prefer B or C.
Thanks. Why do you see those as better?
>
> The "annotation hell" you see in A may feel a bit typesafe at first, but for every string value like
> @SubscriptionName("mySubName1") if you pick the wrong name it won't work and you get an error during runtime or
> appropriate tests only.
>
> Especially for "name" or "Id" types of information that feels overengineered.
I don't think this is an issue of type safety, since the various properties have the same type in all options. So
subscription name is a String (just like in the rest of JMS), acknowledgement mode is an enumerated type, etc.
However what you don't get in option A is any help from the IDE that if you, say, specify
@SubscriptionDurability(SubscriptionDurability.Mode.DURABLE)
you may also want to specify
@SubscriptionName("mySubName1")
whereas in Option B if you specify
@JMSDurableTopicListener
the IDE will be able to tell you that the available (but optional) attributes are destinationLookup,
connectionFactoryLookup, clientId, subscriptionName, messageSelector and acknowledge.
However I'm not sure how important that is.
Nigel
>
> Werner
>
>
> On Fri, Sep 11, 2015 at 3:13 AM, <users-request_at_jms-spec.java.net <mailto:users-request_at_jms-spec.java.net>> wrote:
>
> Table of contents:
>
> 1. [jms-spec users] JMS_SPEC-116: JMS MDB improvements: simplifying the annotations - Nigel Deakin
> <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>>
>
>
>
> ---------- Forwarded message ----------
> From: Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>>
> To: users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net>
> Cc:
> Date: Thu, 10 Sep 2015 17:21:09 +0100
> Subject: [jms-spec users] JMS_SPEC-116: JMS MDB improvements: simplifying the annotations
> I'm continuing to work through some of the issues raised on my proposals to improve JMS MDBs at
> https://java.net/projects/jms-spec/pages/JMSListener2. To help readers I'm starting a new thread for each issue.
>
> I'd like to review the proposed new method annotations for JMS MDBs in a bit more detail. These are the
> annotations that would (1) specify that a method was a callback method and (2) specify which messages should be
> delivered to it.
>
> Recap of current proposal
> -------------------------
>
> The following example illustrates the annotations currently proposed:
>
> @JMSListener(lookup="java:global/java:global/Trades",type=JMSListener.Type.TOPIC )
> @JMSConnectionFactory("java:global/MyCF")
> @SubscriptionDurability(SubscriptionDurability.Mode.DURABLE)
> @ClientId("myClientID1")
> @SubscriptionName("mySubName1")
> @MessageSelector("ticker='ORCL'")
> @JMSListenerProperty(name="foo1", value="bar1")
> @JMSListenerProperty(name="foo2", value="bar2")
> @Acknowledge(Acknowledge.Mode.DUPS_OK_ACKNOWLEDGE)
> public void giveMeAMessage(Message message) {
> ...
> }
>
> Obviously, this is an extreme example which demonstrates the use of every annotation. I'm including the new
> @JMSListenerProperty annotation I proposed a few days ago.
>
> @JMSListener is always required: this is the annotation that signifies that this is a callback method. That's why
> the name is "JMSListener" rather than "JMSDestination", despite its role being to specify the queue or topic.
>
> In @JMSListener, the lookup attribute can be omitted. This was to allow the MDB to use "legacy" ways to define the
> queue or topic, such as using the MessageDriven's mappedName attribute. This would also allow an additional
> attribute such as "name" to be added in the future which allows the queue or topic's "non-portable" name to be
> specified.
>
> However in @JMSListener, the type attribute would always be required. I proposed this because the spec does not
> define a default value and it seemed useful to allow the app server/resource adapter to know what type of
> destination was expected.
>
> Otherwise, there is a separate annotation corresponding to each of the standard activation properties.
>
> Discussion
> ----------
>
> There are a number of things we should review here. I think the main thing we need to consider is which is better:
>
> a. to have lots of separate annotations, almost all of which have a single attribute, or
>
> b. to have a smaller number of annotations, each of which set multiple attributes.
>
> An alternative proposal
> -----------------------
>
> I'd like to suggest an alternative set of annotations:
>
> One for queues:
>
> @JMSQueueListener(destinationLookup="java:global/java:global/Trades",
> connectionFactoryLookup="java:global/MyCF",
> messageSelector=""ticker='ORCL'",
> acknowledge=JMSQueueListener.Mode.DUPS_OK_ACKNOWLEDGE)
> @JMSListenerProperty(name="foo1", value="bar1")
> @JMSListenerProperty(name="foo2", value="bar2")
> public void giveMeAMessage(Message message) {
> ...
> }
>
> One for durable topic subscriptions:
>
> @JMSDurableTopicListener(destinationLookup="java:global/java:global/Trades",
> connectionFactoryLookup="java:global/MyCF",
> clientId="myClientID1",
> subscriptionName="mySubName1",
> messageSelector=""ticker='ORCL'",
> acknowledge=JMSQueueListener.Mode.DUPS_OK_ACKNOWLEDGE)
> @JMSListenerProperty(name="foo1", value="bar1")
> @JMSListenerProperty(name="foo2", value="bar2")
> public void giveMeAMessage(Message message) {
> ...
> }
>
>
> One for nondurable topic subscriptions:
>
> @JMSNonDurableTopicListener(destinationLookup="java:global/java:global/Trades",
> connectionFactoryLookup="java:global/MyCF",
> messageSelector=""ticker='ORCL'",
> acknowledge=JMSQueueListener.Mode.DUPS_OK_ACKNOWLEDGE)
> @JMSListenerProperty(name="foo1", value="bar1")
> @JMSListenerProperty(name="foo2", value="bar2")
> public void giveMeAMessage(Message message) {
> ...
> }
>
> Some of these attributes would need to be specified, others would be optional.
>
> Having separate annotations for queues, durable subscriptions and non-durable subscriptions would remove the need
> for the user to specify destinationType or subscriptionDurability as attributes.
>
> Possible further option
> -----------------------
>
> In addition to the alternative above, we could also offer a completely generic annotation, though this would
> strictly be unnecessary:
>
> @JMSDestinationListener(destinationLookup="java:global/java:global/Trades",
> type=JMSListener.DestinationType.TOPIC,
> connectionFactoryLookup="java:global/MyCF",
> clientId="myClientID1",
> subscriptionDurability=JMSListener.SubscriptionDurability.DURABLE
> subscriptionName="mySubName1",
> messageSelector=""ticker='ORCL'",
> acknowledge=JMSQueueListener.Mode.DUPS_OK_ACKNOWLEDGE)
> @JMSListenerProperty(name="foo1", value="bar1")
> @JMSListenerProperty(name="foo2", value="bar2")
> public void giveMeAMessage(Message message) {
> ...
> }
>
> This generic annotation would need to allow destinationType and subscriptionDurability to be specified.
>
> What do you think?
> ------------------
>
> What do you think? Do you prefer:
>
> A. One annotation @JMSListener to define the callback method and the destination
> One small annotation for every other activation property
> (the original proposals)
>
> B. One big annotation JMSQueueListener for queues,
> One big annotation JMSDurableTopicListener for durable topic subscriptions,
> One big annotation JMSNonDurableTopicListener for nondurable topic subscriptions,
> One small annotation JMSListenerProperty for each non-standard activation property
> (the alternative proposals above).
>
> C The same as B plus
> The generic JMSDestinationListener annotation
>
> D. The generic JMSDestinationListener annotation (only)
> One small annotation JMSListenerProperty for each non-standard activation property
>
> I don't have a strong view on which is better: it's mainly a matter of style. One advantage of having annotations
> with multiple attributes is that once the user has decided which annotation to use, the IDE would offer hints as
> to which attributes to set.
>
> Nigel
>
>
>
>
> End of digest for list users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net> - Fri, 11 Sep 2015
>
>