I've now made the appropriate API and javadoc changes, so you can now see the updated javadocs for JMSContext and the
new javadocs for JMSProducer at
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html
The changes are as already described at
http://java.net/projects/jms-spec/pages/JMSContextScopeProposalsv4p4
I haven't updated the draft spec itself yet.
Please let me know if you have any questions or comments.
Nigel
On 02/08/2012 15:47, Nigel Deakin wrote:
> 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