Created attachment 25037 [details] Full error log. After compilation of a JSP fails, Tomcat will often still try to use the (non-existant) cached version. For example, I have a simple JSP containing only "Hello, <%=name%>". When accessing for the first time, Tomcat throws "org.apache.jasper.JasperException: Unable to compile class for JSP". Subsequent requests will alternate between this error, and "java.lang.ClassNotFoundException: org.apache.jsp.jsp.test_jsp". In the case of editing existing JSPs which have compiled fine, the response will alternate between the original error, and the cache of the last-good JSP. I'm using Sun JVM 1.6.0_18-b07.
This has been fixed in trunk and proposed for 6.0.x
After some discussion, a modified patch has been applied and proposed. The issue is that immediately re-trying the compilation increases the risk of a DOS attack. Whilst JSP compilation failures shouldn't happen in production, they often do. The new approach adds a new init parameter for the JSP servlet that controls if failed compilations are immediately retried on the next access or if modificationTestInterval is honour. This only applies in development mode. For versions where this feature is not available, consider setting modificationTestInterval to 0. Again the same warning re DOS applies.
Thanks for following up on this issue. Does the proposed patch also address the case when a JSP has compiled and cached successfully and is subsequently edited with some syntax error? In this situation Tomcat seems to not invalidate the cache.
This has been fixed in 6.0.x and will be included in 6.0.26 onwards.