John,
That's a reasonable question. However the actual available values are different in the two cases:
In ConnectionFactory#createContext or Connection#createSession there are four options which specify:
- Auto-ack
- Dups-ok ack
- Client ack
- Local transaction
whereas with JMS MDBs there are two, or perhaps three, options which are
- Auto-ack
- Dups-ok ack
- XA transaction (though we may not be able to have this as an option since XA transactions are configured using EJB
annotations)
You can never have local transactions (JMSContext#commit) or client acknowledgement (message.acknowledge()) when using a
MDB.
So if we used the same integer constants as for MDBs we would risk confusing the user into thinking they can specify
client acknowledgement or local transactions.
This is reflected in the current EJB spec, which defines that acknowledgeMode may only be set to the strings
"Auto-acknowledge" and "Dups-ok-acknowledge".
The options available for flexible JMS MDBs should reflect the options available for a MDB. It needs to be obvious to
the user that the range of options available is different than when calling ConnectionFactory#createContext or
Connection#createSession.
We could reuse the existing string constants, but that's rather old fashioned. That's why I think we should use either
an enumerated type or separate annotations. I don't have a strong view which, though using separate annotations is
slightly less verbose.
Nigel
On 17/11/2015 12:55, John D. Ament wrote:
> 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 <mailto: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
>
>