Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 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
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 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 thathttps://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

Back to the top