You may remember that we still have not conclusively defined how the injection of JMSContext objects will work. Back in
April I asked a number of questions, and received a number of responses, which I summarise further down in this email.
The main conclusion I drew from the discussion back then was that the definition in the Early Draft (which I repeat
below) was just about right. The style of the annotation was about right, and the idea of having a separate JMSContext
instance for every injection point received strong support from just about everyone, despite my trying to make the case
for dropping it and using normal CDI sharing instead. So these aspects of the spec seem to be OK.
However there was a general feeling the scope of the injected JMSContext objects should be changed from "request" to a
new scope that took account of transactions.
Since I don't think that JMS should be defining its own scope in isolation, I have been working with Pete Muir (CDI spec
lead) and Reza Rahman to develop a definition of "transaction scope" which could be added to CDI, and made use of by
JMS. Reza has proposed this to the CDI expert group for discussion, and I would like to propose it to the JMS expert
group (and everyone else) as well. This definition of "transaction scope" is designed to include the important and valid
case where there is no transaction.
I have now created a detailed wiki page
http://java.net/projects/jms-spec/pages/JMSContextScopeUseCases
which recaps what the Early Draft says, explains why "request" scope isn't quite right for JMS, and describes Reza's new
proposal for transaction scope. I then give nine use cases which demonstrate what this would mean for Java EE
applications which used JMS.
Please take a look and let me have your comments.
Nigel
*Appendix: *Below is a summary of the Early Draft proposal, and a summary of the responses to the questions I asked back
in April.
Here is what the Early Draft proposes:
On 05/04/2012 16:40, Nigel Deakin wrote:
> *Recap of Early Draft proposal*
>
> The current proposals are as described in section 11.3 "Injection of JMSContext" objects of the Early Draft. Here's a
> concise version of what it says,
>
> /This section relates to application classes which run in the Java EE web, EJB or application client containers and
> which support injection. Section EE.5 of the Java EE specification lists the application classes that support injection.
>
> Applications may declare a field of type javax.jms.JMSContext and annotate it with the javax.inject.Inject annotation:
>
> The container will inject a JMSContext. It will have request scope and will be automatically closed when the request
> ends. However, unlike a normal CDI request-scoped object, a separate JMSContext instance will be injected for every
> injection point.
>
> @Inject
> private JMSContext context;
>
> The following annotations may be added to specify the injected JMSContext in more detail:
>
> @JMSConnectionFactory("jms/connectionFactory") - used to specify the lookup name of the connection factory
> @JMSPasswordCredential(userName="admin",password="mypassword") - used to specify the user/password passed to
> createConnection
> @JMSSessionMode(JMSContext.AUTO_ACKNOWLEDGE) - used to specify the session mode of the JMSContext (subject to existing
> JavaEE restrictions)
> @JMSAutoStart(false) - used to prevent the connection being started automatically
> /
I asked a number of questions about this, to which I received several replies. Here's a reminder of the questions and a
summary of the responses:
> /Question 1: Should the injection of JMSContext be tied to CDI or should we simply define the injection behaviour we
> require? A=Yes, B=No
> /
A - Rüdiger zu Dohna
A - Reza Rahman
B: John Ament
Pete Muir (CDI Spec Lead) reminded us that the standard Java EE approach to injection was to use CDI (i.e. A).
I think the A's have it. In discussions generally I didn't encounter any enthusiasm for inventing some new annotation to
use instead of @Inject, and in the absence of a strong reason for doing so I think we should keep this as a CDI feature.
> ///Question 2: Should there be a separate instance for each injection point (answer A), or should normal CDI sharing
> (according to scope) be used? (answer B)/
>
A: Rüdiger zu Dohna
A: Reza Rahman
John Ament replied, but didn't explicitly state a preference. He wrote "Injecting into multiple stateless session
beans, or even stateful session beans, should result in different instances." which sounds closer to A.
You may remember I tried to make a case for (B), since this was the normal CDI way to do things, but received
surprisingly little support both in this EG and from colleagues. The comment I most often received was that sharing the
same injected JMSContext between two different beans within the same context was simply too "surprising".
So I think we should stick with A (which is that we had in the early draft)
> /Question 3: Even if the session and connection are shared, should the producer properties listed above still have
> dependent scope? (A=yes, B=no)
> /
This question was only relevant if we choose B to the previous question. I didn't phrase this question very well, but
what I had in mind was Rüdiger's suggestion that the connection, session and producer were shared between injection
points within the same scope, but that the producer properties deliveryMode, priority, expiry, and future delivery time
were not.
A: Rüdiger zu Dohna
John Ament replied, but didn't explicitly state a preference. he wrote "The properties should be set against the
instance, not a proxy." which sounds like A.
Reza Rahman wrote "I don't think the instances should be shared, but if they are, the producer properties should not be
shared" which sounds like A.
> /
> //Question 4: Should the scope of the injected JMSContext be (A) request or (B) extended to cover any transaction as
> well?/
> /
> /
B: Rüdiger zu Dohna (but no strong opinion)
"The scope should be a combination of request and transaction, whichever one is longer" - Reza Rahman
B: John Ament
Having a scope which is related to the transaction seems to have general support, so I asked Pete Muir (CDI spec lead)
what plans there were for CDI to support a "transaction scope". Pete asked the CDI community whether anyone would like
to develop a proposal, and Reza Rahman stepped forward. Reza, Pete and I had some discussions about what was suitable
for JMS and Reza has made a proposal called @TransactionScoped which I would characterise as "the scope is the
transaction, or the method, whichever is longer". Since there was a general support for relating the scope to the
transaction, I would now like to bring this proposal to this Expert Group. Please see
http://java.net/projects/jms-spec/pages/JMSContextScopeUseCases for details.
> /Question 5: Do you prefer (A) multiple small annotations, similar to qualifiers (@JMSConnectionFactory,
> @JMSPasswordCredential, @JMSSessionMode and @SessionMode) or (B) a single annotation with many attributes
> (@JMSContextConfiguration)/
>
A: Rüdiger zu Dohna (but no strong opinion)
A - Reza Rahman
Both simultaneously: John Ament
Some colleagues within Oracle suggested (B)
I think this is really a matter of API style. In the absence of a strong reason for changing, I propose we stick with
what we have in the Early Draft, which is A.
Nigel