We held our first virtual meeting at 0900 PST on Thursday 12 Nov 2015.
Note to everyone: although this meeting discussed the content of JMS 2.1 and came to various conclusions about what
would be in it, I'm aware that there are plenty of people who were not there. Please feel free to reply to this email
and make comments, proposals or other suggestions. Additional contributions are welcome!"
To those who were present: feel free to reply add corrections or clarifications, or ad anything I have missed.
Please be reminded that this meeting is not restricted to expert group members. All who wish to contribute to JMS 2.1
are invited.
I've created a page containing meeting agenda, minutes and Zoom/phone details. This is
https://java.net/projects/jms-spec/pages/JMS21Meetings
Next meeting
------------
The general aim is to hold these meetings every two weeks. However since this would clash with the US Thanksgiving
holiday, the next meeting will be on ONE week on Thursday 19 Nov 2015, again at 0900 PDT.
Agenda
------
The agenda was at
https://java.net/projects/jms-spec/lists/users/archive/2015-11/message/1
This was a video/web conference using Zoom. This worked well. (Nigel found that seeing everyone on video helped a lot,
and he shared his screen so we could all look at the same wiki page)
1. Introductions
----------------
Nigel Deakin (Oracle, Spec lead, UTC)
Tom Barnes (Oracle, UTC-5)
Chris Barrow (Kaazing, EG member, UTC-8)
David Blevins (Tomitribe, EG member, UTC-8)
2. Flexible JMS MDBs: discussion of method annotations
------------------------------------------------------
Most of the meeting was spent on this. Nigel has previously circulated a summary of the main proposals made so far:
https://java.net/projects/jms-spec/pages/JMSListener4
Option A was Nigel's original proposal (included here because it has some similarities with option F)
Option B was the proposal contained in Early Draft 1
Option F was a slightly-modified version of the proposals that came out of the face-to-face meeting on 29th Oct.
Option G was an amendment to Option G from Tom Barnes (which had not been discussed before)
Basic principles
----------------
The discussion started by establishing some basic principles for these annotations:
* There would be one annotation (or a set of alternative annotations) which must only be specified on the callback
method in order to identify that the method was a callback method. Since its main purpose was to identify a callback
method we would not allow it to be specified as a class annotation. So @Target(value=METHOD)
* Other annotations could be specified either on the method or on the class. Annotations on the method would probably
override a conflicting annotation on the class (or we could consider this an error: this was not discussed). So
Target(value={METHOD, TYPE})
* On the issue of whether to allow multiple callbacks, Nigel explained that he was generally in favour, and had
implemented them successfully in the RI's resource adapter, he had discovered some problems implementing them
efficiently in app servers which don't use a resource adapter. To avoid getting bogged down in these issues (which may
require spec changes or a disproportionate amount of work for vendors), he proposed that for the time being the spec
should allow only one callback method. This will allow us to make progress with flexible MDBs without getting bogged
down in these issues. If time permits we would return to this within JMS 2.1.
* Despite deferring support for multiple callbacks, we would design the annotations so that they would support multiple
callbacks, so we wouldn't need to change the annotations if we decided later to allow them.
The discussion proper started with Option F, the proposal which arose out of the face-to-face meeting two weeks ago.
The callback annotation
-----------------------
First the "callback-identifying" annotation. The minutes of the last meeting has described this as being:
@OnMessage(lookup="java:global/requestQueue", type=javax.jms.Queue)
and
@OnMessage(lookup="java:global/someTopic", type=javax.jms.Topic)
Nigel explained that in his write-up on the wiki (see link above) he had changed this to
@OnMessage(java:global/requestQueue")
@Queue
and
@OnMessage(java:global/someTopic")
@Topic
Currently it is undefined whether the user needs to specify the type of the destination. A discussion followed on
whether this should be (1) undefined as at present, (2) always optional or (3) always required. Tom expressed his view
that we should require the user to specify what destination type their MDB was intended to use, and (of a topic) whether
a durable or non-durable subscription. Tom then introduced his proposal in Option G for
@JMSQueueListener(java:global/java:global/requestQueue")
and
@JMSNonDurableTopicListener("java:global/java:global/someTopic")
and
@JMSDurableTopicListener(java:global/java:global/someTopic")
After a discussion it was agreed that forcing the user to specify whether a queue or topic was expected was a good idea.
There was less certainty about whether to force the user whether, if a topic were being used, the subscription was
durable or non-durable. It might be simpler to assume that topic subscriptions were non-durable unless the user had
specified that the subscription was durable.
There was also a feeling that annotations containing the word "Listener" were inappropriate, and annotations containing
the word "non" were inelegant. This led the discussion to consider
@OnMessageQueue(java:global/java:global/requestQueue")
and
@OnMessageNonDurableTopic("java:global/java:global/someTopic")
and
@OnMessageDurableTopic(java:global/java:global/someTopic")
though there was a feeling that we should look for better names. An alternative would be that instead of having three
alternatives, where were two main alternatives (queue or topic) where topic has two modes (durable or non-durable). This
would led us to:
@OnMessageQueue(java:global/java:global/requestQueue")
and
@NonDurable
@OnMessageTopic("java:global/java:global/someTopic")
and
@Durable
@OnMessageTopic("java:global/java:global/someTopic")
with the single annotation
@OnMessageTopic("java:global/java:global/someTopic")
defaulting to non-durable.
That was where that part of the discussion ended.
AcknowledgeMode annotations
---------------------------
The meeting went on to discuss the annotations to specify acknowledgeMode.
Option F proposed @DupsOKAcknowledge (and no annotation for auto-ack).
Option G (based on Tom's ideas) proposed that we have define three QoS annotations: @DupsOKAcknowledge,
@AutoAcknowledge, @javax.jms.Transactional. These would either (1) behave as assertions, so deployment would fail if the
value of @TransactionManagement was inconsistent, or (2) we would not allow @TransactionManagement to be set and
instead use these three QoS annotations to determine whether bean-managed-transactions or container-manager-transactions
were used.
After discussion, it was agreed that(2) was not possible. @TransactionManagement was probably too profound a EJB/MDB
concept for us to want to try to replace it with something new. We were probably stuck with it. We were also probably
stuck with the basic EJB/MDB principle that by default the message was received in a transaction. Changing either would
end up making things more confusing, not less.
It was agreed that we should try to adopt (1), which would cause deployment to fail if @DupsOKAcknowledge,
@AutoAcknowledge or @javax.jms.Transactional were specified but the value of @TransactionManagement was inconsistent.
However
It might be best not to define @javax.jms.Transactional, since this would be confused with
javax.transaction.Transactional (which we couldn't use as it had elements which were not relevant here).
This would leave us with just @DupsOKAcknowledge and @AutoAcknowledge
There might not be sufficient standard API to allow a RA to discover whether CMT or BMT was configured and hence fail
deployment if there was a conflicting @DupsOKAcknowledge, @AutoAcknowledge.
So we would probably need to say something like "it is an error to use conflicting annotations. The container or
resource adapter is recommended to detect this and fail deployment, though this is not mandatory"
We would definitely *not* say that @DupsOKAcknowledge and @AutoAcknowledge would be ignored if there was a conflicting
value of @TransactionManagement.
3. Flexible JMS MDBs: issues relating to multiple callback methods
------------------------------------------------------------------
We spend much time on this. Nigel simply stated that he had discovered some problems implementing them efficiently in
app servers which don't use a resource adapter and this would require more work. To avoid getting bogged down in this,
he proposed that for the time being the spec should allow only one callback method. This would allow us to make progress
with flexible MDBs without getting bogged down in these issues. If time permits we would return to this within JMS 2.1.
4. Next meeting
---------------
At the next meeting we would continue working on the method annotations (perhaps coming to a conclusion) before moving
on to discussing the method signature itself.
Nigel