Hi Mark
I think we're just moved from asking what the spec says, to what should the spec say. Since I'm off the opinion the spec doesn't actually tell us if CDI.current should or shouldn't be guaranteed to work if you create a new thread without Jakarta concurrency,
moving the conversation in this direction seems sensible.
From a technical perspective I have no objections to clarifying the spec to say CDI.current should work in new threads and of course Mark is all in favour. What do the good folks at Weld think?
Regards
Benjamin
This Message Is From an External Sender
This message came from outside your organization.
Hi Benj!
Those are all valid arguments.
But this is not about enterprise beans managing threads.
Please let me explain our problem: The very specific case we do have is about a classic Java utility (commons-pool2) creates a new (Evictor-) Thread, even sets the TCCL properly for this new Thread. It does all that in a non-EE way, as this library doesn't
know where it runs in.
In this new Thread we use CDI.current().getBeanManager() to access an @ApplicationScoped Bean and even the access to @RequestScoped beans should be valid if properly setup via all the SE APIs, e.g.
RequestContextController.
If this doesn't work, then it does really defeat the purpose why we introduced all those APIs, isn't?
Again: I'm not expecting JTA, EJBs, etc to work - just pure CDI-SE APIs.
LieGrue,
strub
> 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
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
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
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
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
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
