I think it looks good. I of course like the third option best. I hope
others weigh in as well...
On 6/29/2012 1:33 PM, Nigel Deakin wrote:
> On 17/06/2012 17:25, Reza Rahman wrote:
>> I do really like your idea of splitting the JMS context state and
>> connection/session -- it seems like a very elegant solution.
>
> Thanks. I think that idea merits being written up in more detail. I've
> therefore expanded my previous wiki page of use cases so that it to
> cover *two* alternative proposals which make use of @TransactionScoped.
>
> The proposal in the Early Draft is now called "option 1" (request
> scope, separate JMSContext instance for each injection point)
>
> The proposal I made on 1st June is called "option 2" (transaction
> scope, separate JMSContext instance for each injection point)
>
> This third proposal is called "option 3" (transaction scope, except
> for the producer's javabean properties)
>
> I've divided the updated proposals into two pages:
>
> Introduction and proposals
> http://java.net/projects/jms-spec/pages/JMSContextScopeProposals
>
> Use cases
> http://java.net/projects/jms-spec/pages/JMSContextScopeProposals2
>
> To see the difference between the option 2 and 3, look at use case C.
>
> Please have a look and make any comments by Friday 6th July if
> possible - we really need to get this issue wrapped up since
> implementation work has already started!
>
>> BTW, I suspect the effort to standardize the transaction scope is
>> unlikely
>> to happen in a timely fashion (this is my second attempt at it in the
>> CDI EG
>> and things seem to stall both times for various somewhat inexplicable
>> reasons). I think we should consider simply defining a JMS context
>> specific
>> scope to keep things moving along and see if that can be adopted by
>> the CDI
>> EG (or some other EG) at some later point in time. As such, this is the
>> precedent in JPA, JSF, etc anyway.
>
> Hmm. Yes, that's unfortunate but may be what we have to do. I think
> this EG should decide what *we* want, and then we can have one last
> attempt at getting CDI to adopt it.
>
> Thanks,
>
> Nigel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2171 / Virus Database: 2437/5100 - Release Date: 06/29/12
>
>