John,
That's definitely good news. @TransactionScoped has far broader
implications than just JMS. We should definitely double-check on the
actual priority/progress of this though. It does seem contrary to the
opinion expressed here:
http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2011-06/message/22.
It would be interesting to see how they tackle the issue of transaction
manager look-up non-portability...
I doubt a generic @TransactionScoped would suffice for the purposes of
JMS 2 though (with or without producers/disposers). For example, in
order to maintain JMS object inter-dependencies, you'd still have to
ensure that related objects are created/destroyed in the correct order
(with object destruction order being the real tricky part). In order to
ensure that, what is really needed is a custom scope that binds objects
to the transaction and is aware of the hierarchy/relationships between
the objects in the transactional context I think.
I really think the best bet for us is to define the scope/features that
we really need for JMS 2 and see how well that fits (or does not fit)
into standard scopes/features defined in CDI/EJB (as long as things are
generally congruent).
That being said, if you can think of a solution to these issues by
sticking strictly to CDI standard scopes/producers+disposers, that would
definitely be a good thing. Similarly, we should explore (ideally via a
quick and dirty prototype) if it is best to use qualifiers vs. plain
annotations. If qualifiers inhibit usability in this case, perhaps it is
best to forgo them?
Look forward to chatting more on Monday...
Cheers,
Reza
On 9/6/2011 3:33 PM, John D. Ament wrote:
> Nigel, Reza,
>
> As a follow up to today's call, I can confirm that it is currently
> proposed to add a TransactionScope to the CDI spec.
> https://issues.jboss.org/browse/CDI-121
>
> John