Oh actually sorry I just realized I have a conflict with a tri-weekly
meeting on Thurs so would not be able to make 12th Nov or 6 weeks later,
etc (I could only make every two out of three meetings). Mon, Tue or Wed
would be work better for me.
Chris
On 10/30/2015 2:25 PM, Chris Barrow wrote:
> Hi Nigel,
>
> 0900 Pacific on alternate Thursdays, starting 12th Nov is fine for me.
>
> Chris
>
> On 10/30/2015 2:18 PM, Nigel Deakin wrote:
>> 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.
>>
>>
>>
>>
>>
>