https://bz.apache.org/bugzilla/show_bug.cgi?id=66161
Mark Thomas <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mark Thomas <[email protected]> --- The short answer is that Tomcat 9.0.60 onwards is behaving correctly in this case. Unfortunately, the fix introduced in https://github.com/apache/tomcat/commit/d4050b4cc979302c5f5cc9237609e1564fa367c4 exposed an issue with EmptyNullStringResolver. For the app's use of beans, the app wants null values to remain null (contrary to the EL spec). For the app's use of String.conact(), the app wants null values converted to empty string (consistent with EL spec). Having behaviour consistent with EL spec in one case and contrary to the spec in another is going to require some hoop jumping. There are lots of ways you could work-around this. My suggestion is to handle this in EmptyNullStringResolver. If it overrides invoke() with something like this: @Override public Object invoke(ELContext context, Object base, Object method, Class<?>[] paramTypes, Object[] params) { if ((base instanceof String) && "concat".equals(method) && params.length == 1 && "".equals(params[0])) { context.setPropertyResolved(true); return base; } return super.invoke(context, base, method, paramTypes, params); } It can treat concat as a special case any bypass the EL type conversion when call with null. The code above is only lightly tested and intended to give you an ideas of how you might address this issue. I am resolving this as invalid since Tomcat's behaviour is spec compliant in this case. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
