Given a JSP page, and some object bound to a request attribute called "foo", I can refer to "foo" with:
${foo}
If the value of "foo" has a bean property called, say, "type", and the type of "type" is some enum
class, then to make comparisons I would use a string:
<c:if test='${foo.type == "WHATEVER"}'>
Then assuming that one of the constants in my enum
class has the name "WHATEVER", that comparison should work, and produce either true
or false
.
Now what I'm wondering is how exactly that comparison is supposed to be carried out by the servlet container. Some Oracle documentation (here) suggests (vaguely) that what happens is that the string constant is converted to the enum
type, and then the comparison is made.
I'm investigating a situation involving code that I think works differently between Jetty/Tomcat (ie, Apache) and Resin. The Apache world seems to be doing the right thing, or at least the thing that I'd expect according to that documentation from Oracle.
What I fear is that another property of my enum
may be causing the Resin implementation to do something different. Specifically, my enum
class has a .toString()
implementation that returns a different string than that returned by .name()
. That quirk causes no problems in an Apache server, or at least none that I've ever seen. If Resin implements the comparison by converting the enum constant to a string (via .toString()
, not .name()
) instead of converting the string to the enum
type, then things won't work consistently.
Note that in all other respects I'm having no issues with using my enum
types (lots of them are like this) in various other ways in JSP/JSTL/EL. There are in fact only a small number of places where there's EL logic in the JSP, because the application does most of its work via client-side template rendering.
edit — I'm pretty sure I confirmed that Resin does the comparisons differently, though I don't know exactly what that is. I have (for reasons I don't recall) a "name" EL function in my own EL function library, so I can use that to work around the problem.
Unfortunately Resin is processing incorrectly. I've filed a bug at http://bugs.caucho.com/view.php?id=5925