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.
The time is a little early. 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).
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> 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>
> 2. [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements: - Nigel Deakin
> <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>
> 4. [jms-spec users] Re: JMS_SPEC-116: JMS MDB improvements: - Nigel Deakin
> <nigel.deakin_at_oracle.com>
>
>
>
> ---------- Forwarded message ----------
> From: David Heffelfinger <dheffelfinger_at_gmail.com>
> To: 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>
> 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 - 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>
> To: 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>
> To: 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>
> 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>
> To: 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>> 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 - Wed, 18 Nov 2015
>
>