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