[wildfly-dev] [jboss-as7-dev] Fwd: jboss-el-api_2.2_spec APIs and Wildfly

[Stuart Douglas]

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 at 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 at redhat.com>
> > To: "Shelly McGowan" <smcgowan at redhat.com>
> > Cc: "Remy Maucherat" <rmaucher at 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 at redhat.com>
> >> To: "Remy Maucherat" <rmaucher at redhat.com>
> >> Cc: "Stuart Douglas" <sdouglas at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130729/a0f6d829/attachment.html