| [cdi-dev] Spec question about application context |
|
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 |