Please can you share a bit more detail on what kind of changes you are proposing to the Transactions specification
The Transactions specification provides a CDI build-in bean to make the UserTransaction type injectable by CDI.
and whether you see those changes as necessary (like bug fixes) or enhancements
Depending on how you look at it, it's a bug fix, but an architectural one. CDI is the core spec on which other specifications depend. Other specifications should know about CDI, CDI should not know about those other specifications (as much as is reasonably possible).
To make the dependency graph, and who-owns-what more consistent. Any enhancement to how UserTransaction is injected or any clarification thereof, should be done by the Jakarta Transactions specification, and not by the CDI specification. CDI has no business describing that. This is equivalent to CDI having no business describing how say FacesContext from Jakarta Faces is injected (which instance, from where, at what moment during the Faces lifecycle, etc).
Practically, an implementation of Jakarta Transactions that already uses CDI to manage several of its artefacts, would have to jump through some hoops since CDI itself takes possession of its UserTransaction artefact. I'm running somewhat into this with the Jakarta Transactions implementation Transact (
https://github.com/OmniFish-EE/omni-transact), but the proposal is beyond that.
Hope this makes it more clear.
Kind regards,
Arjan Tijms
Hi,
The Jakarta Transactions spec takes care of the @Transactional interceptor and the @TransactionScoped scope. However, the injection of UserTransaction is specified by the CDI spec.
As UserTransaction is owned by Jakarta Transactions, I think it should be Jakarta Transactions that is responsible for making sure this type is injectable.
Thoughts?
Kind regards,
Arjan Tijms
_______________________________________________
jta-dev mailing list
jta-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev
_______________________________________________
jta-dev mailing list
jta-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev