For the session based annotations, why not rely on the existing constants?
I know its less than ideal, but it at least makes it more consistent from a
developer's standpoint.
John
On Tue, Nov 17, 2015 at 7:46 AM Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
> Following last week's video meeting, I've now written an updated summary
> of here:
> https://java.net/projects/jms-spec/pages/JMSListener5
> (I'm calling this option H)
>
> There are draft javadocs at
> https://jms-spec.java.net/2.1-OPTION-H-SNAPSHOT/apidocs/
>
> Note that this covers only the method/class annotations (those that set
> activation properties). We haven't reviewed the
> various options for method parameters yet.
>
> I have highlighted a number of open issues (marked in bold in the text):
>
> * Which is better: a single @DurableSubscription annotation with two
> elements to set the name of the durable
> subscription and the clientId, or three separate annotations
> @DurableSubscription, @SubscriptionName, @ClientId?
>
> * We've defined @DupsOKAcknowledge and @AutoAcknowledge and recommended
> that deployment fails if the user has forgotten
> to configure bean-managed transactions. Should we also define a new
> annotation like @Transaction or @AssertTransaction
> and recommended that deployment fails if the user has configured
> bean-managed transactions?
>
> * The annotations @JMSConnectionFactory, @MessageSelector,
> @DupsOKAcknowledge, @AutoAcknowledge, @ListenerProperty may
> be specified on either the callback method or on class. If an annotation
> is specified on the class then it applies to
> all callback methods. What happens if the user specifies conflicting
> annotations at the two levels? Is this an error, or
> does one override the other?
>
> * What if a user sets activation properties, especially if they conflict
> with one of the new annotations? Should
> activation properties always be ignored, should they override the new
> annotations, or should a conflict cause a
> deployment error?
>
> We'll discuss this at our next meeting on Thursday 19th, or you can reply
> to this email.
>
> I'm hoping that our next meeting can move on to discussing the callback
> method itself, the various options for method
> parameters, and how errors should be handled.
>
> Reminder: Next meeting at 0900 PST on Thursday 19th Nov.
> Meeting details are at
> https://java.net/projects/jms-spec/pages/JMS21Meetings
>
> Nigel
>
>
>