Re: [cdi-dev] Spec question about application context

[Benjamin Confino <BENJAMIC@xxxxxxxxxx>]

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

---

From: Matej Novotny <manovotn@xxxxxxxxxx>
Sent: 30 August 2024 08:17
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Cc: Benjamin Confino <BENJAMIC@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [cdi-dev] Spec question about application context

 

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

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

On Thu, Aug 29, 2024 at 10:17 PM Benjamin Confino via cdi-dev <cdi-dev@xxxxxxxxxxx> wrote:

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