Excellent. It's good to see those in the draft. The example looks good.
Nick
Nicholas Wright
Senior Consultant
/C2B2 Consulting Ltd
/*The Leading Independent Middleware Experts*/
/W: www.c2b2.co.uk| T: (+44) 8450 539457| M: (+44) 7703 193351|
@c2b2consulting
---------------------------------------------------------------------------------------------------------------
C2B2 Consulting Limited, Unit 34, Malvern Hills Science Park, Geraldine
Road, Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered Office: Ardendale,
Old Hollow, Malvern, Worcestershire
On 03/09/2012 17:08, Nigel Deakin wrote:
> 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