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?
On Mon, Jul 29, 2013 at 7:25 PM, Shelly McGowan <smcgowan(a)redhat.com> wrote:
On a related note to this discussion about EL 3.0 APIs:
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
>> EL 3.0 APIs and implementation.
>> I'm assuming the plan is to keep this in for at least WildFly
>> 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
>> 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
>> an org.wildfly.el module to include only this class as you can see on
>> [NOTE: there are a couple of unrelated changes in that branch]
>> This work was prompted by some signature test failures I was seeing in
>> The EL 2.2 APIs being in the distribution were unrelated.
>> Shelly McGowan
>> JBoss, by Red Hat
jboss-as7-dev mailing list