As you pointed out, this compromises the goals of the simplified API a bit, but I can't think of a better solution short of reintroducing what I am guessing has already been vetted out as being too complex/confusing. Not too bad overall though -- I think we should move forward...
> -----Original Message-----
> From: Nigel Deakin [mailto:nigel.deakin_at_oracle.com]
> Sent: Thursday, August 02, 2012 10:47 AM
> To: jsr343-experts_at_jms-spec.java.net
> Subject: [jsr343-experts] Re: (JMS_SPEC-64) Define simplified JMS API
>
> 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