Tim ZöllerMar 9

Do I know anybody who is really experienced with #JakartaEE and especially #CDI and would be interested to look at a behavior in an OSS repository with me?

Roughly summarized, calling an EL expression in one deployed war, which uses a bean in a different war? Used to work before CDI 4, now doesn’t anymore

Edit: For the curious: https://github.com/operaton/operaton/pull/2527

#Tomcat

fix(engine): enable process application context switch for EL express… by javahippie · Pull Request #2527 · operaton/operaton

…ion evaluation Fixes #2522 When evaluating EL expressions via JuelExpression.getValue(VariableScope), the contextExecution was always null, preventing the DefaultDelegateInterceptor from switching...

GitHub
Show threadFalk
@javahippie did the war and/or class loading order change?
Mar 9 at 6:45pmWeb
Show threadTim ZöllerMar 9
@derunglaublichefalk It’s now dependent on the deployment order, wasn’t before (link now added)
Show threadFalkMar 9
@javahippie Im quite sure I had such a problem in the past, but really cannot remember how I fixed that.
I would need to setup a workspace to take a closer look
Show threadFalkMar 9
@javahippie maybe a good idea to not only search for projects...
Show threadFalkMar 12
@javahippie I have to admit, before setting everything up to debug the object instantiation in that specific situation I have some more important and less painful things to do... sorry.
I would have had a look in the injection and object retrieaval code in CDI. Maybe at least that approach is useful
Show threadTim ZöllerMar 12
@derunglaublichefalk I dug into it a little, and there is a mechanism that we inherited from Camunda: In Tomcat, every deployment has its own classloader, so there is a contextlookup: If a context is not available in its own deployment. This switching doesn't happen for EL expressions in this case. I'm not sure why it stopped working with CDI 4.0, that would be really interesting, but I'm still diving into that one...
Show threadFalkMar 12
@javahippie perhaps a change in the behavior of the classloader hirarchy leads to an undiscoverable context. The problem is you mustn't rely on any deployment order and the change which creates your problem could be just a different call order somewhere in CDI.
Maybe also an very reduced example can reproduce the problem and make it more understandable