On Aug 30, 2016, at 12:05 AM, Stuart Douglas
<stuart.w.douglas(a)gmail.com> wrote:
You probably need to import services:
<module name="org.glassfish.javax.el" services="import" />
Doesn’t seem to make a difference. Interestingly, there doesn’t seem to be a
META-INF/services entry of any kind in the module.
After doing some more investigating I think I’ve sorted it out.
My CDI extension creates an ExpressionFactory lazily, during a CDI ProcessInjectionPoint
event callback.
In Wildfly 10, when my CDI extension’s ProcessInjectionPoint event observers are being
called, the TCCL is not set.
In Wildfly 9, the TCCL was set to the deployment class loader. Looking at the source for
the Glassfish EL implementation, it seems to want to use the TCCL to locate the
ExpressionFactory implementation.
I’m thinking that my extension worked in Wildfly 9 only because there was an EL provider
on the deployment class loader (since that’s the TCCL) — it really didn’t matter whether
my module declared a dependency on the EL provider, since the module’s class loader wasn’t
involved.
I changed my extension so that it sets the TCCL to the module class loader before creating
the EL ExpressionFactory. Now it uses the correct class loader and it doesn’t matter
whether a deployment has an EL provider on its class loader; the declared dependency on
the Glassfish EL provider in my module descriptor is all that’s needed.
carl