The first JMS 2.1 meeting was held in San Francisco on 19 Oct 2015. (This was a face-to-face meeting only)
(Please see the proposal for further meetings below.
Can people make 0900 Pacific on alternate Thursdays, starting 12th Nov?)
The agenda was at
https://java.net/projects/jms-spec/pages/JSR368Meeting1
1. Introductions
----------------
Nigel Deakin (Spec lead)
Chris Barrow (EG member)
Werner Keil (EG member)
Ivar Grimstad (EG member)
David Blevins (EG member)
David Hellefinger
Everyone introduced themselves and outlined their interest in JMS 2.1.
2. Improving collaboration
--------------------------
Everyone was keen to hold regular meetings using voice/video/screensharing/chat technology. We could use Zoom, which is
the Oracle corporate solution so can accommodate many users, or Google Hangouts, which is limited to 10 video users, or
something else. Nigel was happy to experiment.
We provisionally agreed to hold a meeting every two weeks on Thursdays at 0900 PST, which will be 1700 UK, 1800 CDT. (We
have EG members in India and South Korea, for whom these times would probably not work. Please let me know if you'd like
to attend but can't make that time)
There was a discussion about alternatives to Email. This is our main form of communication. Old emails are archived
online at
https://java.net/projects/jms-spec/lists/users/archive though the UI is poor. We also have JIRA, which allows
us to have discussions on a specific issue. Chris recommended using Slack (slack.com), which Nigel would take a look at.
Any other suggestions?
3. Proposed high-level plan for JMS 2.1
---------------------------------------
Nigel introduced a high-level plan of features planned for JMS 2.1, in approximate priority order. The idea was that we
would work through these in order and try to avoid having a lot of incomplete features in progress at the same time. The
actual list of features is based on the original JSR 368 proposal so shouldn't contain any surprises. If anyone has a
favourite feature that they think has been missed from this list, please say so.
Note that this is a plan for *discussing* features: features will only go into JMS 2.1 after the community has had an
opportunity to discuss and agree on a detailed proposal. Note also that we will run out of time at some stage.
The high-level plan is now at
https://java.net/projects/jms-spec/pages/JMS21Plan
4. Review of EDR1: Flexible JMS MDBs
------------------------------------
We had a general discussion of the new flexible JMS MDB annotations in the Early Draft.
4.1 "no-methods" marker interface
---------------------------------
Nigel reminded the meeting that EJB 3.2 currently forces us to use a "no-methods" marker interface, proposed to be
JMSMessageDrivenBean. He had proposed that this requirement be removed from the EJB spec and has logged
https://java.net/jira/browse/EJB_SPEC-127.
David suggested that the EJB spec define an annotation rather than an interface. So instead of
@MessageDriven
public class MyMessageBean implements JMSMessageDrivenBean {
we would need to use something like
@JMSMessageDrivenBean
@MessageDriven
public class MyMessageBean {
Nigel said it would be better if the EJB spec would remove the requirement for either, perhaps by giving special status
to MDBs with the (say) @JMSQueueListener etc or @OnMessage annotation.
4.2 Multiple callback methods
-----------------------------
Everyone supported allowing a JMS MDB to have multiple callback methods.
4.3 Method annotations
----------------------
The current proposals are for @JMSQueueListener, @JMSNonDurableTopicListener and @JMSDurableTopicListener annotations,
plus @JMSListenerProperties for ad-hoc properties.
David suggested shorter annotation names, and having more, smaller annotations.
Existing EDR proposal for a queue with a message selector and dups-ok:
@TransactionManagement(value=TransactionManagementType.BEAN)
@MessageDriven
public class MyMessageBean implements JMSMessageDrivenBean {
@JMSQueueListener(
destinationLookup="java:global/requestQueue",
connectionFactoryLookup="java:global/connectionFactory",
messageSelector="JMSType = 'car' AND colour = 'pink'",
acknowledge=JMSQueueListener.Mode.DUPS_OK_ACKNOWLEDGE
)
public void myMessageCallback(Message message) {
...
}
}
suggested alternative proposal for a queue with dups-ok:
@TransactionManagement(value=TransactionManagementType.BEAN)
@MessageDriven
public class MyMessageBean implements JMSMessageDrivenBean {
@DupsOK
@Selector("JMSType = 'car' AND colour = 'pink'")
@JMSConnectionFactory("java:global/connectionFactory")
@OnMessage(lookup="java:global/requestQueue", type=javax.jms.Queue)
public void myMessageCallback(Message message) {
...
}
}
EDR proposal for a durable subscription:
@MessageDriven
public class MyMessageBean implements JMSMessageDrivenBean {
@JMSDurableTopicListener(
destinationLookup="java:global/requestQueue",
connectionFactoryLookup="java:global/connectionFactory",
subscriptionName="subname",
clientId="myClientID"
)
public void myMessageCallback(Message message) {
...
}
}
suggested alternative:
@MessageDriven
public class MyMessageBean implements JMSMessageDrivenBean {
@DurableSubscription(name="subname", clientId="myClientID")
@OnMessage(lookup="java:global/prices", type=javax.jms.Topic)
public void myMessageCallback(Message message) {
...
}
}
Incompatible combinations would cause a deployment error.
Annotations (except @OnMessage) could be placed at class level as well as method level, in which they would apply to all
callback methods. (We'd need to define what would happen if an annotation was set at both levels.)
4.4 Flexible method signature
-----------------------------
David suggested we allow the use of JAX-RS-style parameter converters, to allow user-pluggable converters between
messages and any parameter type.
Nigel said that if we did this we'd need to add a corresponding facility when creating or sending messages.
This suggestion needs to be worked into a more detailed proposal.
5. CDI beans as JMS message listeners
-------------------------------------
The meeting also discussed the proposals for CDI beans to listen for JMS messages. Things have now moved on since
Nigel's original proposals, and the most likely approach is to tackle only dependent-scoped and application-scoped
beans, and in both cases to follow the behaviour of CDI events.
If the listener bean has dependent scope, then create a consumer at startup and then, for every message,
(1) Create a new instance of the bean
(2) Invoke the callback
(3) Destroy the instance.
If the listener bean has application scope, then create a consumer at startup and then, for every message,
(1) Obtain the sole contextual instance of the bean, creating it if necessary
(2) Invoke the callback
In both cases we would probably want to allow messages to be delivered concurrently using multiple threads, with an
annotation to define the maximum number of threads. In the case of application scope this would mean the same instance
was called from multiple thread. This should not be seen as a problem since application scoped CDI beans are not
intended to be single-threaded - and even if JMS were to define threading rules for the callback method, JMS has no
control over what other methods the application might be calling at the same time.
Nigel will circulate updated proposals over the next couple of weeks.
6. Other topics
---------------
The JMS 2.1 specification document is currently in Microsoft Word 2007 format and is available in svn at
https://java.net/projects/jms-spec/sources/repository/content/jms2.1/specification/word/JMS21.docx
David offered to assign someone to converting it to ASCIIDoc. Nigel welcomed the suggestion. Nigel added that he wanted
to add numbered "TCK assertions" for all changes.