On a related note to this discussion about EL 3.0 APIs: http://lists.jboss.org/pipermail/jboss-as7-dev/2013-July/008179.html See below a previous exchange on an attempt to remove EL 2.2 API dependency from WildFly. Shelly McGowan JBoss, by Red Hat > ----- Forwarded Message ----- > From: "Stuart Douglas" <sdouglas(a)redhat.com&gt; > To: "Shelly McGowan" <smcgowan(a)redhat.com&gt; > Cc: "Remy Maucherat" <rmaucher(a)redhat.com&gt; > 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. > > Stuart > > ----- Original Message ----- >> From: "Shelly McGowan" <smcgowan(a)redhat.com&gt; >> To: "Remy Maucherat" <rmaucher(a)redhat.com&gt; >> Cc: "Stuart Douglas" <sdouglas(a)redhat.com&gt; >> Sent: Thursday, 18 July, 2013 9:45:01 AM >> Subject: jboss-el-api_2.2_spec APIs >> >> >> >> Remy, >> >> 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: >> undertow/src/main/java/org/wildfly/extension/undertow/deployment/ELExpressionFactoryProcessor.java >> web/src/main/java/org/jboss/as/web/deployment/ELExpressionFactoryProcessor.java >> >> 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 >> branch: >> https://github.com/smcgowan/wildfly/commit/3c511ea2e74a22215f02d69ff0d07d... >> >> [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 _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 07/29/2013 10:08 PM, Stuart Douglas wrote: > I think we should just be importing the EL 3.0 API into our github > repo and using the resulting org.jboss.spec artifacts for the API. > > Looking at the repo it looks like this has already been imported, is > there any reason we can't just use this? There's a packaging issue with the RI, which has the EL API + impl inside the same JAR. OTOH, it should be ok to focus on the spec support first, then see how to improve this later. Rémy _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 07/30/2013 08:22 AM, Stuart Douglas wrote: > In that case why don't we just import the whole thing into a github > repo and just repackage the whole thing? Sure, but IMO a bit later. Right now, I'm using the RI, but it's possible I switch (back) to the Tomcat impl which is getting ready for EL3 [in that case your class should work just fine]. So is it possible to wait ? The "EL3" checkbox is more or less covered, this should take care of the urgency of the issue. Rémy _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev