Hi Nigel,
I will try to join today.
Regards,
Vaquar khan
8308511500
On 19 Nov 2015 15:30, "Ivar Grimstad" <ivar.grimstad_at_gmail.com> wrote:
> 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
>>>
>>>
>>
>>