I've now made the corresponding spec changes to match the changes already made to the javadocs to add the new
JMSProducer interface.
The updated draft spec is here:
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
In section 11.2 "Key features of the simplified API", the following subsections have been updated:
11.2.1. JMSContext - updated to mention JMSProducer
11.2.4. Sending messages - completely re-written to cover JMSProducer
In addition a new example has been added which shows how the JMSProducer can be used to set properties on a message.
This is 11.4.3. Sending a message with properties (Java SE).
Here's the example in a nutshell:
context.createProducer().setProperty("foo","bar").setTimeToLive(10000).
setDeliveryMode(NON_PERSISTENT).setDisableMessageTimestamp(true).send(inboundQueue, payload);
Please let me know if you have any comments.
Nigel
On 08/08/2012 17:48, Nigel Deakin wrote:
> 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