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? 

Stuart


On Mon, Jul 29, 2013 at 7:25 PM, Shelly McGowan <smcgowan@redhat.com> wrote:

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@redhat.com>
> To: "Shelly McGowan" <smcgowan@redhat.com>
> Cc: "Remy Maucherat" <rmaucher@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.
>
> Stuart
>
> ----- Original Message -----
>> From: "Shelly McGowan" <smcgowan@redhat.com>
>> To: "Remy Maucherat" <rmaucher@redhat.com>
>> Cc: "Stuart Douglas" <sdouglas@redhat.com>
>> 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/3c511ea2e74a22215f02d69ff0d07d32bafb798d
>>
>> [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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev