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)