Nigel,
I'm available Tuesday. 0900 isn't great, as I am on a call right before it
and want to give a few extra minutes for it. Would 0930 or 1000 be ok?
John
On Fri, Sep 2, 2011 at 5:34 PM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> Nigel,
>
> I agree a conference call is the way to go. The time works for me, but I am
> flexible.
>
> Cheers,
> Reza
>
>
>
> On 9/2/2011 12:04 PM, Nigel Deakin wrote:
>
>> John, Reza, All,
>>
>> Just to reiterate, I think we're definitely on the right track with the
>> @Inject (DI) proposal. I think we've got the scope about right in providing
>> an improved API that could be used by both Java EE and Java SE users. I look
>> forward to devoting time to reviewing John's Event Messaging proposal but I
>> think we should focus on @Inject initially and see how much progress we can
>> make.
>>
>> We've only had comments from me and Reza so far. I'd like to move forward
>> quickly on this, so if others do want to get involved and make comments then
>> please do so soon. I shall assume that the absense of comments from an EG
>> member means you don't have any strong views, are happy for others to take
>> the proposal forward, and won't be making fundamental objections in the
>> future.
>>
>> Reza has reminded us that he did make some suggestions earlier. I think
>> this is a reference to his email of 21/22 July, in which he made some
>> suggestions but deliberately avoided giving much detail. One thing I'd like
>> to understand is what differences, if any, there are between the two
>> approaches.
>>
>> Can I suggest we have a conference call to discuss that and the other
>> issues raised so far? I'm thinking of John, Reza and me but any EG member is
>> welcome to join.
>>
>> There's a US holiday on Monday. How about Tuesday 6th Sept at 0900 EDT,
>> 1400 BST? I can make any time that day, so please suggest any other times
>> (or days) that work.
>>
>> Nigel
>>
>>
>>
>>
>>
>> Some of the topics we need to cover are listed below. This isn't intended
>> to be a complete list but could form an initial agenda for the call.
>>
>> Big questions
>> -------------
>>
>> * Will the new API depend on CDI - either CDI 1.0 (JSR 299) or the
>> prospective CDI 1.1 (JSR 346) - or merely on Atinject (JSR 330)? Is it
>> necessary to enable the new API to be implemented using using Atinject (but
>> non-CDI) frameworks such as Guice or Spring?
>>
>> * What should the scope of injected JMS objects be? Do we need to
>> prescribe a new scope not currently offered by CDI (e.g. Reza's "transaction
>> scope")? If we decide that the CDI scopes are inadequate this may steer us
>> away from direct dependence on CDI, or perhaps we should seek changes to
>> CDI.
>>
>> Medium questions
>> ----------------
>>
>> * What changes to the basic API are needed to support message injection?
>> Possibilities include:
>> - New MessageFactory interface obtained using ServiceLoader mechanism
>> - New message factory methods on ConnectionFactory
>> - Keep existing methods on Session but clarify messages may be used in
>> any session
>> - Keep existing methods on Session with no need to clarify messages may
>> be used in any session
>>
>> * Do we need @JmsCredentials
>> - Need at least for SE use only, perhaps
>> - Perhaps discuss what createConnection(user,**password) means in Java
>> EE?
>>
>> * New convenience methods for "implicit conversion" between message types
>> and payload types
>>
>> * JmsDestinationLiteral, JmsConnectionLiteral or JmsCredentialsLiteral
>>
>> * ConnectionProducer
>> - why is this needed?
>>
>> * Are @JmsConnection, @JmsDestination qualifiers or annotations?
>>
>> Small questions
>> ---------------
>>
>> * Do we need a new SessionType enumeration (rather than using
>> Session.CLIENT_ACKNOWLEDGE etc)
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1392 / Virus Database: 1520/3872 - Release Date: 09/02/11
>>
>>
>>
>