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
>
>