See below a previous exchange on an attempt to remove EL 2.2 API dependency from WildFly.
JBoss, by Red Hat
----- Forwarded Message -----
From: "Stuart Douglas" <sdouglas(a)redhat.com>
To: "Shelly McGowan" <smcgowan(a)redhat.com>
Cc: "Remy Maucherat" <rmaucher(a)redhat.com>
Sent: Thursday, July 18, 2013 1:00:15 AM
Subject: Re: jboss-el-api_2.2_spec APIs
I created this class to address a fairly major EL performance issue (that factory finder
is invoked on every EL invocation, and it is both slow and acquires locks, which cause
lots of contention).
We may need to do a similar performance fix in the org.glassfish EL module, but I am not
really sure. Assuming the problem still exists and we remove this fix our JSF performance
will drop considerably.
----- Original Message -----
> From: "Shelly McGowan" <smcgowan(a)redhat.com>
> To: "Remy Maucherat" <rmaucher(a)redhat.com>
> Cc: "Stuart Douglas" <sdouglas(a)redhat.com>
> Sent: Thursday, 18 July, 2013 9:45:01 AM
> Subject: jboss-el-api_2.2_spec APIs
> Currently in WildFly we are using the org.glassfish:javax.el dependency for
> EL 3.0 APIs and implementation.
> I'm assuming the plan is to keep this in for at least WildFly 8.0.0.Final
> releases (and EE 7 certification) due to Beta1 only a few weeks away.
> I was working on a pull request to remove the EL 2.2 APIs from WildFly and
> found out I was unable to do that due to a dependency
> from both the web module and the undertow module on:
> org.jboss.el.cache.FactoryFinderCache specifically in:
> This class is included in the jboss-el-api Specs project API .jar but
> obviously not part of org.glassfish:javax.el.
> How do you want to handle this moving forward? For tests purposes, I created
> an org.wildfly.el module to include only this class as you can see on this
> [NOTE: there are a couple of unrelated changes in that branch]
> This work was prompted by some signature test failures I was seeing in TCK.
> The EL 2.2 APIs being in the distribution were unrelated.
> Shelly McGowan
> JBoss, by Red Hat