On 22 Oct 2012, at 17:18, Nigel Deakin wrote:
> 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?
>
Yes, for example @TransactionScoped @RequestScoped(ifNotActive=TransactionScoped.class)
or something like that (note this is just an idea right now!)
> Nigel