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.
>
>
>
>
>