We're getting this exception/stack trace in a web application: ''[2010-01-15 17:52:01,381] - ERROR [org.apache.catalina.core.ContainerBase] Exception invoking periodic operation: 'java.lang.NullPointerException at org.apache.jasper.servlet.JspServletWrapper.getServletContext(JspServletWrapper.java:174) at org.apache.jasper.compiler.JspRuntimeContext.checkCompile(JspRuntimeContext.java:304) at org.apache.jasper.servlet.JspServlet.periodicEvent(JspServlet.java:289) at org.apache.catalina.core.StandardWrapper.backgroundProcess(StandardWrapper.java:668) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1571) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1580) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1580) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1580) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1560) at java.lang.Thread.run(Thread.java:595) Looking at JspServletWrapper, I see that it has 2 constructors; one for JSP pages, and another for tag files. The one for tag files has a problem in this line: this.config = null; // not used because this.config is indeed used by the public method getServletContext(): public ServletContext getServletContext() { return config.getServletContext(); } and since that method is public, you can't safely say that this.config will not be used. :) So this means that if you create a JspServletWrapper for a JSP tag file, you can never call getServletContext() on it, or you'll generate the NPE above. However, JspRuntimeContext does exactly that in the following block of code, from the checkCompile() method: Object [] wrappers = jsps.values().toArray(); for (int i = 0; i < wrappers.length; i++ ) { JspServletWrapper jsw = (JspServletWrapper)wrappers[i]; JspCompilationContext ctxt = jsw.getJspEngineContext(); // JspServletWrapper also synchronizes on this when // it detects it has to do a reload synchronized(jsw) { try { ctxt.compile(); } catch (FileNotFoundException ex) { ctxt.incrementRemoved(); } catch (Throwable t) { jsw.getServletContext().log("Background compile failed", t); } } } The values in the "jsps" map are both JSP files and tag files, as seen by TagFileProcessor.loadTagFile(), which puts tag files there. So to summarize, any JSP tag file that experiences a compilation failure inside of the checkCompile() method will seem to generate this NullPointerException. A secondary issue here is that if any problem occurs inside of the catch block in the code pasted above (as is currently happening), the original exception is swallowed forever. This is the Throw From Within Finally anti-pattern (http://today.java.net/article/2006/04/04/exception-handling-antipatterns#throwFromWithinFinally) and should be fixed as well.
I should also have noted that after this NullPointerException occurs, we then continue to get this error over and over: ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/d].[jsp]] Servlet.service() for servlet jsp threw exception 'java.lang.NoClassDefFoundError: org/apache/jsp/tag/meta/internal_002dtitle_tag presumably for the JSP tag file whose compilation failed. I don't know if that's the behavior you want, as the error is pretty cryptic. You may want something more explicit like "compilation of this JSP failed"?
I just confirmed that this issue still affects the latest version (6.0.24).
Fixed in 7.0.x and proposed for 6.0.x
This has been fixed in 6.0.x and will be included in 6.0.25 onwards.
Also fixed in 5.5.x for 5.5.29 onwards