Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jta-dev] [cdi-dev] @Inject UserTransaction in CDI spec, should be in Transactions?
+1. From what I have seen, this is what seems to make the most sense to newer users.
 
From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> on behalf of Ladislav Thon <lthon@xxxxxxxxxx>
Sent: Monday, August 15, 2022 4:02 AM
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Cc: jta developer discussions <jta-dev@xxxxxxxxxxx>
Subject: Re: [cdi-dev] @Inject UserTransaction in CDI spec, should be in Transactions?
 
I agree with Arjan, all these integrations should eventually become part of the respective specifications if possible. If possible means: unless there's a circular dependency (such as between CDI and Servlet), in which case, there's no clear answer.

LT

On Tue, Aug 9, 2022 at 10:36 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

For consistency it's better to have each spec take care of the injection of its own artefacts. E.g. SecurityContext, owned by Security, is not in the CDI spec either but security takes care of making it available for injection. CompositeComponent is owned by Faces and is not in the CDI spec but Faces takes care of making it available for injection.

UserTransaction being in the CDI spec is a historic mistake, caused by the initial confusion whether CDI would become EJB again (Facade over all other specs) or CDI (core that all other specs use).

Kind regards,
Arjan Tijms

On Tue, Aug 9, 2022 at 10:27 AM Emily Jiang via cdi-dev <cdi-dev@xxxxxxxxxxx> wrote:


On Tue, Aug 9, 2022 at 12:12 AM Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
Hi,

The injection of UserTransaction is already mentioned in the Transactions spec, but only as an example how to acquire it using injection (actually 2 examples, one using @Resource injection, another one using @Inject injection). But the spec should be more concrete and at least state that in CDI container, injection using @Inject should be supported and in an EJB container, injection using @Resource should be supported. I don't know if this requirement is covered by any tests in the TCK. If not, then some new tests should cover it.

+1
For CDI, I would leave the requirement there because it's only in the section for Jakarta EE and it neatly summarizes all injectable built-in beans. However, injection of UserTransaction and none of the other beans mentioned in 9.8. Additional built-in beans isn't supported in the new Jakarta EE Core profile. So it would be better if this section is moved to each particular profile if applicable (ie. moved to Full and Web profiles and not to Core profile, at least until there are any built-in beans supported by Core profile).


I don't think it makes sense to move the web profile or platform. I think this section is about Jakarta EE integration. It is applicable to web profile or platform. Besides, the core profile clearly specifies it only requires the CDI Lite section.

All the best,,
Ondro Mihalyi

Director, Jakarta EE expert
OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee
Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Sun, Aug 7, 2022 at 2:30 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
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
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev


--
Thanks
Emily

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev

Back to the top