On 17/11/2015 12:45, Nigel Deakin wrote:
> Following last week's video meeting, I've now written an updated summary here:
> https://java.net/projects/jms-spec/pages/JMSListener5
> (I'm calling this option H)
Following our second video meeting I have updated the proposals on the above page to reflect the (provisional) decision
to have separate annotations for @DurableSubscription, @SubscriptionName and @ClientId
I've also updated it with some new issues raised. The remaining issues (on the issue of JMS MDB class and method
annotations) are:
* NEW ISSUE: Since @AutoAcknowledge and @DupsOKAcknowledge are alternatives and are not valid together, should we
combine them in a single annotation which takes an enumerated type or integer value?
If we defined an enumerated type as a nested class this would look like
@AcknowledgeMode(AcknowledgeMode.Mode.AutoAcknowledge) and @AcknowledgeMode(AcknowledgeMode.Mode.DupsOKAcknowledge)?
Or should the enumerated type be a separate type? If so, what should its name be? (it can't be called AcknowledgeMode
since that's the name as the annotation).
Or should the type be defined using an integer? John Ament suggested reusing the existing sessionType integer annotations.
* 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 3rd Dec, or you can reply to this email.
Nigel