users@jms-spec.java.net

[jms-spec users] Re: Feedback from JavaOne talk

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Mon, 22 Oct 2012 17:18:45 +0100

On 22/10/2012 16:54, Pete Muir wrote:
> On 22 Oct 2012, at 16:42, Nigel Deakin wrote:
>
>> Pete,
>>
>> Thank you very much for these comments (sorry it's taken so long for me to reply).
>>
>> On 10/10/2012 12:01, Pete Muir wrote:
>>> Nigel et al.
>>>
>>> Here is a writeup of the notes I made during Nigel's JavaOne talk on JMS 2.
>>>
>>> 1) The word "Context" in the simplified API JMSContext seems redundant to me, and not very consistent with usage
>>> in other specs. I just wonder if there is a better name for this class (but I don't have one!).
>>
>> A "JMSContext" represents a single-threaded handle on the messaging provider. I chose the word "context" to be
>> vaguely consistent with the JPA concept of PersistenceContext, though it is actually closer to an EntityManager.
>> What specs were you thinking that have a inconsistent use of "context"?
>>
>> The fact that "context" is fairly meaningless was considered a benefit!
>>
>> I did call it MessagingContext initially but changed to JMSContext for reasons of brevity and also to allow a
>> consistent trio of interfaces JMSContext, JMSProducer, JMSConsumer.
>>
>>>
>>> 2) Some feedback for the CDI community comes from the way that JMS wants a "gracefully degrading scope" such
>>> that @TransactionScoped is used if a transaction is in progress, otherwise a request scoped is used. I would hope
>>> to specify this idea in CDI 2.0, hopefully in a way that JMS can then use (as opposed to specifying it directly)
>>
>> Would this expand the definition of @TransactionScoped to state that it degrades to to be the same as
>> @RequestScoped when there was no transaction?
>>
>> How would this relate to whatever the JTA spec lead is planning to say about @TransactionScoped? Should that spec
>> (rather than CDI) define @TransactionScoped as a gracefully degrading scope?
>
> More that you could define a bean to be @TransactionScoped and that *this bean* degrades to @RequestScoped if the
> transaction is not active.

How does that differ from what is currently proposed? Or are you suggesting that the "degrading option" is specified on
the bean somehow?

Nigel