On 18/11/2015 08:32, Werner Keil wrote:
> Hi,
>
> I just arrived at DevoXX and waited for the Bond movie around then last Thursday, so I could not join the meeting. Is
> it a voice call, IRC or Google Hangout now? I remember it was discussed at our F2F during JavaOne.
Zoom video/audio/phone. Windows/Mac/iOS/Android. It worked well last week.
Next meeting at 0900 PST, 1200 Eastern Time, 1700 UK time, 1800 CET on Thursday 19th Nov.
Meeting details are at
https://java.net/projects/jms-spec/pages/JMS21Meetings
Nigel
> The time is a little early.
OK. If you can't join us you're still welcome to make comments by email, and I'll publish minutes of every meeting. If
others would like to join but would attend at a different time, let me know. It's still early days.
> I have just like David client projects to participate in. If it's a voice call, I should be able to dial in either
> from the office or mobile (assuming there's a local Swiss number).
See the list linked from the above page. There is for Switzerland (the main omission is India). Or you can use the
internet for audio (which I did last time).
Nigel
> Everything else depends on how friendly our proxy/firewall is, e.g. IRC I could only use web clients that exist. I
> should be able to attend some meetings if there are no urgent tasks or meetings at the client. Similar to e.g. Portlet
> 3 which I joined yesterday evening (Patrick had cancelled the EC call as he's at the next DevoXX in Morocco, speaking
> today;-)
>
> Werner
>
>
> On Wed, Nov 18, 2015 at 2:13 AM, <users-request_at_jms-spec.java.net <mailto:users-request_at_jms-spec.java.net>> wrote:
>
> Table of contents:
>
> 1. [jms-spec users] Re: Minutes of JMS 2.1 Meeting 2 on 12 Nov 2015 - David Heffelfinger <dheffelfinger_at_gmail.com
> <mailto:dheffelfinger_at_gmail.com>>
> 2. [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements: - Nigel Deakin <nigel.deakin_at_oracle.com
> <mailto:nigel.deakin_at_oracle.com>>
> 3. [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements: - "John D. Ament" <john.d.ament_at_gmail.com
> <mailto:john.d.ament_at_gmail.com>>
> 4. [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements: - Nigel Deakin <nigel.deakin_at_oracle.com
> <mailto:nigel.deakin_at_oracle.com>>
>
>
>
> ---------- Forwarded message ----------
> From: David Heffelfinger <dheffelfinger_at_gmail.com <mailto:dheffelfinger_at_gmail.com>>
> To: users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net>
> Cc:
> Date: Tue, 17 Nov 2015 05:55:50 -0500
> Subject: [jms-spec users] Re: Minutes of JMS 2.1 Meeting 2 on 12 Nov 2015
> Sounds like it was a productive meeting. Sorry I couldn't attend. I'm doing this in my own time, at the time of
> the meeting I was working on a project for a customer.
>
> Hopefully I'll be able to attend one of the future meetings.
>
> David
>
> On Mon, Nov 16, 2015 at 5:17 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> A couple of quick corrections to the minutes:
>
> On 13/11/2015 19:48, Nigel Deakin wrote:
>
>
> 2. Flexible JMS MDBs: discussion of method annotations
> ------------------------------------------------------
>
>
>
>
> The callback annotation
> -----------------------
>
>
> In addition to the other topics mentioned, we also discussed the possibility of using vendor-defined
> annotations to configure non-standard features. These would be more readable, less vulnerable to typos, and
> would allow typed values, which setting non-standard String properties set using
> @JMSListenerProperty(key="foo",value="bar") would not.
>
> By definition, any use of non-standard properties is non-portable. If @JMSListenerProperty is used then the
> application would still compile on a different app server but non-standard properties would be ignored. If
> vendor-defined annotations were used then the application would not compile on a different app server.
>
> It was agreed that although some vendors may wish to define annotations, by definition these would not be
> something the spec could, or would want to, say anything about.
>
>
>
> 3. Flexible JMS MDBs: issues relating to multiple callback methods
> ------------------------------------------------------------------
>
> We spend much time on this.
>
>
> We did *not* spend much time on this.
>
> Nigel
>
>
>
>
> --
> http://ensode.net <http://ensode.net/> - A Guide to Java, Linux and Other Technology Topics
> My Books: http://www.packtpub.com/authors/profiles/david-heffelfinger
> My Video Training: http://www.packtpub.com/java-ee-development-with-netbeans-7/video
> Follow me on Twitter: https://twitter.com/ensode
>
>
> ---------- Forwarded message ----------
> From: Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>>
> To: users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net>
> Cc:
> Date: Tue, 17 Nov 2015 12:45:01 +0000
> Subject: [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements:
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: "John D. Ament" <john.d.ament_at_gmail.com <mailto:john.d.ament_at_gmail.com>>
> To: users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net>
> Cc:
> Date: Tue, 17 Nov 2015 12:55:56 +0000
> Subject: [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements:
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>>
> To: users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net>
> Cc:
> Date: Tue, 17 Nov 2015 15:59:22 +0000
> Subject: [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements:
> 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>
> <mailto: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
>
>
>
> End of digest for list users_at_jms-spec.java.net <mailto:users_at_jms-spec.java.net> - Wed, 18 Nov 2015
>
>