|
> For example, if enterprise beans were allowed to manage threads, the Jakarta EE platform could not manage the life cycle of the enterprise beans, and it could not properly manage transactions.
> Jakarta EE depends on various context information to be available on the thread when interacting with other Jakarta EE services such as JDBC data sources, Jakarta Messaging providers and Jakarta Enterrise Beans.
While neither of these directly mention CDI, they do say that Jakarta EE services may not work properly if the application manages threads without using Jakarta concurrency.
Regards
Benjamin
From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> on behalf of Mark Struberg via cdi-dev <cdi-dev@xxxxxxxxxxx>
Sent: 23 September 2024 13:42
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Cc: Mark Struberg <struberg@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [cdi-dev] Spec question about application context
Hi! We did introduce CDI. current() to enable applications to get access to the BeanManager in places where they have no option to have an injected BeanManager. Can you point me to the place in the spec where the CDI specification or the EE umbrella
Hi!
We did introduce CDI.current() to enable applications to get access to the BeanManager in places where they have no option to have an injected BeanManager.
Can you point me to the place in the spec where the CDI specification or the EE umbrella specification say that this is only limited to Threads started via a ManagedExecutorService?
Thanks and LieGrue,
strub
Am 30.08.2024 um 12:35 schrieb Benjamin Confino via cdi-dev <cdi-dev@xxxxxxxxxxx>:
Hello Matej,
It sounds like we're all on the same page regarding the implementation and the interpretation of the spec as it currently stands. Which leaves only one final question: Do people think the spec should specify something regarding moving between threads so application
and library developers can be confident all implementors will support whatever method they're using to create threads?
Regards
Benjamin
Hello,
your finds in WFLY are correct in that it also uses a mechanism to determine the caller of CDI.current() and uses a TCCL (which in are in turn based on WFLY modules).
To add a little context, this happens because Weld has a structure of [per archive] BMs linked between each other with certain visibility mimicking EE umbrella spec visibility rules - hence the "caller sensitivity" of CDI.current().
As for you questions, I don't think the quoted spec section explains anything in this scenario - there is very little in the spec WRT moving between threads.
Personally, I think your approach makes sense. You need some way to determine the caller and TCCL is an easy way to achieve that.
Matej
Hello
I recently had a customer ask me about CDI.current() in a multithreaded environment. In our webserver we set thread context that when an application invokes CDI.current() we know which application . However, propagating that context to a new thread requires
an application to use an ManagedExecutorService or a similar technique. I did a quick santiy check against wildfly and I see that https://github.com/wildfly/wildfly/blob/main/weld/subsystem/src/main/java/org/jboss/as/weld/WeldProvider.java also
has logic in getCDI() find the right instance of CDI.
My customer believes this is incorrect, and they say the spec just says (they referenced CDI-2.0 section 25.3.1) which says "A Java EE container is required to provide a CDI provider that will allow access to the current container for any Java EE application
or Java EE module which contains enabled beans"
Their interpretation of this is that the spec beanmanager availability only depends on if we're calling CDI.current() within a Java EE application or Java EE module.
What does everyone think? Is it acceptable to depend on ManagedExecutorService to find the right instance of CDI?
Regards
Benjamin
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
_______________________________________________
cdi-dev
mailing list
cdi-dev@xxxxxxxxxxx
To
unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
|
