EL is not resolving methods properly in JSPs

• Type: Bug
• Status: Closed
• Resolution: Won't Fix
• Affects Version/s: 7.0.0 DXP SP2, Master
• Fix Version/s: 7.0.X, Master
• Component/s: Core Infrastructure, Core Infrastructure > Servlet JSP Compiler
• Labels: None

In past Liferay products, JSP compilation has been achieved by the app server. For our team, this meant running at least Tomcat 7.0.54 when using EL statements like the following with overloaded methods (which we do often):

${bean.doSomething(firstArg, secondArg)}

If the doSomething method is overloaded and if more than one signature has 2 arguments, before Tomcat 7.0.54, the JSP compiler would essentially choose randomly between the two methods, rather than making the choice appropriate to the methods passed in (bug reported to Tomcat here: https://bz.apache.org/bugzilla/show_bug.cgi?id=56425). This is essentially the same problem we're seeing now in DXP.

DXP delegates JSP compilation to the org.glassfish javax.el jar imported as a dependency, currently at version 3.0.1-b05.

The problem is in AstValue.getValue. In that method, the Class<?>[] paramTypes variable is always null, as can be seen in AstMethodArguments.getParamTypes. This causes the EL resolver to fall back to counting method params, and ignoring the actual param types.

Tomcat got around this by deriving the param types from the params and then passing those in to help find the right method. Ideally we would do something similar in our code, perhaps by patching the glassfish jar we're using for this logic.