Hi Niger,
I am flying home from Devoxx Morocco this afternoon, so I will not be able
to make it this time either.
Ivar
On Wed, Nov 18, 2015, 17:04 Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> 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> 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
>>
>>
>
>