In this email I would like to propose some changes to the JMSContext API to make it more suitable for injection.
I have described the issue I am trying to solve here:
http://java.net/projects/jms-spec/pages/JMSContextScopeProposalsv4p4#The_problem
Essentially the problem is as follows:
If, within the same scope, different beans, or different methods within the same bean, use an injected JMSContext which
is injected using identical annotations then they will all share the same JMSContext object.
Although this is normal CDI behaviour this is potentially confusing to developers because it means that changing a
property of a JMSContext in one bean would change that property in a JMSContext in a different bean, despite different
variables being used.
This issue applies irrespective of whether the JMSContext has request scope, transaction scope, or some similar scope,
which is why I am keeping this proposal separately from my proposals for a suitable scope.
I have made several previous attempts at addressing this issue:
* The JMS 2.0 Early Draft proposed using a separate JMSContext instance for each injection point. However this prevents
the sharing of message order and XAResource object between different beans within the same scope.
* The proposal described as Option 2 also proposed using a separate JMSContext instance for each injection point, which
had the same drawbacks.
* The proposal described as Option 3 proposed that although the injected JMSContext would have a combined
transaction/method scope, the six JavaBean properties of the JMSContext's underlying MessageProducer would have
dependent scope so that changing a property in one bean would not affact a property in another bean, even if they both
used the same underlying JMSContext . This proposal received some support, but others found it confusing.
I would now like to make a fourth proposal to address this issue. This involves changing the JMSContext object to make
it appear "stateless", so that changes made in one bean cannot affect another bean.
There is a full description of my proposal here:
http://java.net/projects/jms-spec/pages/JMSContextScopeProposalsv4p4
Essentially, it tries to solve the problem by moving the "state" from the JMSContext to a new JMSProducer object. Since
introducing an additional object goes against my goal of simplifying the API, I am proposing that the new JMSProducer
object supports method chaining in a way which is reminiscent of proposals made by some EG members earlier. Here are few
examples:
context.createProducer().setPriority(1).send(destination,message);
context.createProducer().
setDeliveryMode(DeliveryMode.NON_PERSISTENT).setPriority(1).setTimeToLive(1000).send(destination,message);
context.createProducer(). setCompletionListener(completionListener).send(destination,message);
context.createProducer(). setCompletionListener(completionListener).send(destination,"This is a message");
Please take a look at the full description and let me know if you have any questions or comments.
Nigel