I'm breaking this out as a separate issue from bug 7067, originally raised by Hans Bergsten: It's extremely hard to find out which expression is invalid even in a modestly complex page with a few expressions. The line and column number in the exception message are confusing since they refer to the line/column in a single expression, not a line/column in the page (which is basically impossible to accomplish in JSP 1.2). I suggest the complete expression being parsed be included in the exception message. That would make it a lot easier to find out where the problem lies.
Made a few general changes to clean up the formatting of EL exception messages. Changed the token definitions that have multiple forms, like "<" and "lt" - broke each of those out as separate tokens so that the error message would print "<", "lt" as expected tokens, not "<LE>". Customized the error message of the ParseException so that: * the attribute name and value are included in the error message * the line/column numbers are no longer in the error message * the list of expected tokens is put on a single line, not broken out onto separate lines This was done without actually changing the definition of ParseException (in case JavaCC is run again and overwrites any customizations). Also added a catch-all token so that any input can be tokenized, hence no TokenMgrErrors - all errors now show up as ParseExceptions, formatted as described above.
Thanks for the fixes, but I found anouther type of exception thrown by the Evaluator (or the EL, not sure). This is when the specified bean property does not exist, resulting in a message like this: Unable to find a value for "requestUri" in object of class "org.apache.catalina.connector.HttpRequestFacade" using operator "." If the action and attribute name, plus the complete expression, can be added to this type of exception message as well, it would help a lot.
The previous fix only covered parse exceptions (which would be thrown either at runtime or translation time), but didn't cover the purely runtime ELExceptions. Those are now being caught and wrapped with a message indicating the attribute name and value. I don't know if anyone cares, but this might be a slight security problem since it's possible for some of a page's "source code" (i.e., the attribute value expression) to be visible to the end user if an exception makes it out that far. But I suppose exceptions in general can expose a lot of undesirable information to the end user, so this is probably no more of a problem than it has always been.