Repository navigation
Use a new ELContext for every call of the CdiResolver - #4305
Open
adityaanikam wants to merge 2 commits into
Open
adityaanikam wants to merge 2 commits into
adityaanikam wants to merge 2 commits into
Conversation
CdiResolver created one jakarta.el.ELContext in its constructor and passed it to the resolver of the CDI container on every call. Weld keeps its stack of creational contexts in that context and its lookup of a @dependent bean checks if the stack is empty, pushes, peeks and pops. When jobs on several threads use the same CdiResolver, one thread can pop while another one still peeks, which fails with an EmptyStackException. Create the context per call with createELContext(), which replaces the protected context field.
filiphr
requested changes
Oct 12, 2026
filiphr
left a comment
filiphr
left a comment
Contributor
There was a problem hiding this comment.
Thanks for the PR @adityaanikam. Shouldn't we maybe store the jakarta context on the Flowable ELContext instead of creating it always?
It is created once for each Flowable context instead of for every call.
Author
|
Good point, thanks. The jakarta context is now stored on the Flowable ELContext and created once for each one. I added a test that checks it is reused for the same context |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CdiResolvercreated onejakarta.el.ELContextin its constructor and passed it to the resolver of the CDI container on every call. Ajakarta.el.ELContextmust not be shared between threads, and Weld keeps a stack of creational contexts in it: its lookup of a@Dependentbean checks if the stack is empty, pushes, peeks and pops. When asynchronous jobs on several threads evaluate expressions through the sameCdiResolver, one thread can pop the entry while another one still peeks, which fails with anEmptyStackException.The context is now created for every call with
createELContext(), so calls that run at the same time no longer share it. A call on one thread behaves as before, because the stack is empty at the start of every lookup. ThecreateELContext()method replaces the protectedcontextfield and the constructor ofCdiResolver.CdiResolverTestlets two threads call the resolver at the same time and checks that they get different contexts. I did not reproduce theEmptyStackExceptionitself with Weld, the test covers the shared context that causes it.Fixes #4302
Check List: