jsr343-experts@jms-spec.java.net

[jsr343-experts] Re: [jms-spec users] Re: Re: JMS Support for DI

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Mon, 05 Sep 2011 10:08:40 +0100

John,

Thanks. How about 1000 EDT on Tuesday. (1500 BST)?

(If anyone other than John and Reza wants to join just let me know and I'll send you the dial-in details)

Nigel

On 02/09/2011 23:06, John D. Ament wrote:
> 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 <mailto: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 <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3872 - Release Date: 09/02/11
>
>
>
>