https://bz.apache.org/bugzilla/show_bug.cgi?id=66235
Bug ID: 66235
Summary: Java Beans Standard not honoured in EL expressions
when running under Graal VM (JVM Runtime Mode)
Product: Tomcat 9
Version: 9.0.x
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
Assignee: dev@tomcat.apache.org
Reporter: matthias.hil...@mgm-tp.com
Target Milestone: -----
I recently tried to run an existing application under tomcat 9 with the Graal
VM in JVM Runtime Mode, that means not as an Native exceutable, see
https://www.graalvm.org/22.2/docs/introduction/#runtime-modes ).
I have a class similar like
public class MyBean {
public String getText(Locale locale) { ... }
public String getText() { ... }
}
When I use an EL expression like ${pageScope.mybean.text} it fails (returns
null/an empty string) under certain conditions.
I think the problem is the following:
a) the JasperELResolver uses an GraalBeanELResolver when it thinks it runs
under graal (see
https://github.com/apache/tomcat/blob/main/java/org/apache/jasper/el/JasperELResolver.java#L72
), I'm not sure if the GraalBeanELResolver would be really needed under Graal
VM in JVM Runtime mode as this one should support reflection. But at the moment
the JasperELResolver/JspRuntimeLibrary.GRAAL is configured to to so.
b) the GraalBeanELResolver tries to find the getter of my property, see
https://github.com/apache/tomcat/blob/79173cfbcaf6e82972cce98fbdc619e227037ab8/java/org/apache/jasper/el/JasperELResolver.java#L243
, to do so it simply iterates over all methods and tries to find "getText", it
simply uses the first one. In my example above it depends on the order of
beanClass.getMethods() if this will succeed at the end.
I think the GraalBeanELResolver should use the same logic as the default
BeanELResolver which uses the java.beans.PropertyDescriptor.getReadMethod, this
means to:
- only search for getters without arguments
- also honor the special "is" logic for boolean arguments
I only checked the code for reading (getValue) at the moment, but I guess also
the setValue might have similar issues.
You might say that the above class MyBean is a bad architecture, but
nevertheless with Graal VM the application behaves different than with standard
JDK.
Above I wrote that the code fails in my case under "certain conditions". The
exact difference was that it only failed when I had an
"serletContext.setAttribute(ELInterpreterFactory.EL_INTERPRETER_CLASS_NAME,
someCustomElInterpreter);"
in place. Nevertheless, this custom el interpreter did not interprete this
special el expression on its own but used JspUtil.interpreterCall (which usees
the default mechanism). But while debugging I saw that the main difference was
the order of beanClass.getMethods() inside GraalBeanELResolver. I don't know
how this order is determined. But in my optinion the GraalBeanELResolver should
not rely on any specific order as the javadoc of getMethods says: "The elements
in the returned array are not sorted and are not in any particular order."
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
