| Re: [jta-dev] @Inject UserTransaction in CDI spec, should be in Transactions? |
On Tue, Aug 16, 2022 at 12:50 PM wrote:
TJ> Please can you share a bit more detail on what kind of changes you
TJ> are proposing to the Transactions specification
On 2022-08-16 Arjan Tijms wrote:
AT> The Transactions specification provides a CDI build-in bean to
AT> make the UserTransaction type injectable by CDI.
TJ> and whether you see those changes as necessary (like bug fixes) or
TJ> enhancements
AT> Depending on how you look at it, it's a bug fix, but an
AT> architectural one. CDI is the core spec on which other
AT> specifications depend. Other specifications should know about CDI,
AT> CDI should not know about those other specifications (as much as
AT> is reasonably possible).
TJ> and why?
AT> To make the dependency graph, and who-owns-what more
AT> consistent. Any enhancement to how UserTransaction is injected or
AT> any clarification thereof, should be done by the Jakarta
AT> Transactions specification, and not by the CDI specification. CDI
AT> has no business describing that. This is equivalent to CDI having
AT> no business describing how say FacesContext from Jakarta Faces is
AT> injected (which instance, from where, at what moment during the
AT> Faces lifecycle, etc).
AT> Practically, an implementation of Jakarta Transactions that
AT> already uses CDI to manage several of its artefacts, would have to
AT> jump through some hoops since CDI itself takes possession of its
AT> UserTransaction artefact. I'm running somewhat into this with the
AT> Jakarta Transactions implementation Transact
AT> (https://github.com/OmniFish-EE/omni-transact), but the proposal
AT> is beyond that.
I am entering into this discussion one whole calendar quarter late. I
would like to know the resolution of Arjan's original question. Was
any decision taken on this matter?
_______________________________________________
Thanks,
Ed
| edburns@xxxxxxxxxxxxx | office: +1 954 727 1095
| Calendar Booking: https://aka.ms/meetedburns
|
| Please don't feel obliged to read or reply to this e-mail outside
| of your normal working hours.
jta-dev mailing list
jta-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev