Develop Reference

getOutputStream() has already been called for this response error

Exception :
org.apache.jasper.JasperException: java.lang.IllegalStateException: getOutputStream() has already been called for this response
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:584)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:466)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
root cause :
java.lang.IllegalStateException: getOutputStream() has already been called for this response
org.apache.catalina.connector.Response.getWriter(Response.java:627)
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:215)
javax.servlet.ServletResponseWrapper.getWriter(ServletResponseWrapper.java:105)
org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:125)
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:118)
org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:190)
org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:123)
org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:80)
org.apache.jsp.DownloadResume_jsp._jspService(DownloadResume_jsp.java:91)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)

I think I also got this error when I was working with jasper reports with Struts.
What happen was after creating the report I still returned a value(null) from the Action class(Servlet/Controller). The issue is, the report was set to the HTTPResponse and it is generated and I returned the response from the Action class again.
I just commented the return part from the Action class and then it worked.
Hope this will solve your issue.
Thanks.

Is this a standard error from Apache Tomcat?

I'm receiving this error while accessing in the index page of my JSP project.
Sep 3, 2013 12:03:14 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [jsp] in context with path [/MyProject] threw exception [java.lang.NullPointerException] with root
cause
java.lang.NullPointerException
at org.apache.jsp.index_jsp._jspService(index_jsp.java:126)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
I guess this is a "standard error" from TomCat but I can't find out what is the real problem.

It's a java.lang.NullPointerException in your JSP page, but I take it you'd figured that out already.
JSP pages are converted/compiled to Java - thus the (index_jsp.java:126) in the stacktrace - but unfortunately you can't use the line number for figuring out the problem as it doesn't relate to your JSP file, but the resulting Java source.
You should, however, be able to figure out where the NPE happens by inspection, since your JSP is of course a thin presentation layer, right :-) A usual mistake could be referencing attributes that aren't provided on entry to the page, eg. request.getParameter( "something" ).equals( "somethingelse" ) <-- possible NPE on .equals()
If you were to share the JSP page (perhaps in the form of an SSCCE), this community can help much better.
Cheers,

It's not a "Tomcat standard" error. Its an error in your source code. JSP is translated to java and java.lang.NullPointerException signifies that somewhere you are trying to use some variable without properly initializing it. Or you may have expected it to be initialized but it hasn't due to some resource being unavailable.

You CAN use the line number to find the error. (The answer by Anders R. Bystrup incorrectly says the opposite "...unfortunately you can't use the line number for figuring out the problem".)
It's true the JSP pages are converted to Java and thus the line number does not correspond to the line number in your JSP, but you can find the converted Java file in your work directory, somewhere like:
${TOMCAT_HOME}/work/Catalina/localhost/_/org/apache/jsp/index_jsp.java
and looking at the given line number (126) in that file should point you toward the problem in your JSP (there will likely be an identical line in your JSP).
As others have already pointed out, in this case you have an NPE.

Handle HTTP status 500

In my JSP page I use this script:
<script type="text/javascript">
$("#birthDate").datepicker({ dateFormat: 'dd/mm/yy' });
$("#update").click(function (e) {
var res = true;
var alertMsg = "";
$(".required").each(function (index) {
if (this.value == null || this.value.length == 0) {
alertMsg += this.name + " can't be empty! \n";
res = false;
}
});
if (res) {
var response = $("#updateForm").submit();
Window.location.reload();
} else {
alert(alertMsg);
}
})
But, requested resource is not available, and I get this exception:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
java.lang.RuntimeException: org.springframework.remoting.RemoteAccessException: Could not access remote service at [http://some.resource.com]; nested exception is javax.xml.ws.WebServiceException: java.lang.IllegalStateException: Current event not START_ELEMENT or END_ELEMENT
com.dn.eb.controller.UpdateAccountServlet.throwException(UpdateAccountServlet.java:140)
com.dn.eb.controller.UpdateAccountServlet.doPost(UpdateAccountServlet.java:122)
javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
root cause
org.springframework.remoting.RemoteAccessException: Could not access remote service at [http://some.resource.com]; nested exception is javax.xml.ws.WebServiceException: java.lang.IllegalStateException: Current event not START_ELEMENT or END_ELEMENT
org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.doInvoke(JaxWsPortClientInterceptor.java:510)
org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.invoke(JaxWsPortClientInterceptor.java:487)
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
$Proxy98.updateAccountRecord(Unknown Source)
com.dn.eb.controller.UpdateAccountServlet.doPost(UpdateAccountServlet.java:117)
javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
How can handle this exception, so that on my page displays the error message?

You need to declare the error page in the web.xml :
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/error.jsp</location>
</error-page>
Now any Throwable thrown by the app will invoke the error.jsp.Or this way :
<error-page>
<error-code>500</error-code>
<location>/error.jsp</location>
</error-page>
All 500 errors will invoke error.jsp.
error.jsp is an error page which can be used to display error messages , declare the page directive in error.jsp:
<%# page isErrorPage="true"%>
This gives your JSP an handle to the implicit exception object.

You should see the actual response from your remote side. Most probably you'll see some boilerplate HTML saying your resource wasn't found, you are not authorized, or something similar instead of the actual WS response. This can happen when the WS server is hidden behind an Apache front end, which is misconfigured to assume you are a browser.

Need help understanding an exception in Tomcat servlet

I have the following exception:
Servlet.service() for servlet indexpage threw exception java.lang.NullPointerException
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:675)
at org.apache.catalina.servlets.DefaultServlet.doHead(DefaultServlet.java:351)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at planplatform.cors.CorsFilter.doFilter(CorsFilter.java:61)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Unknown Source)
The only code in this exception that is mine is the CorsFilter:
HttpServletRequest req = (HttpServletRequest) servletRequest;
HttpServletResponse resp = (HttpServletResponse) servletResponse;
String origin = req.getHeader("Origin");
boolean shouldAllowCorsOnOrigin = allowCorsOnOrigin(origin);
if (shouldAllowCorsOnOrigin)
{
resp.addHeader("Access-Control-Allow-Origin", origin);
resp.addHeader("Access-Control-Allow-Credentials", "true");
resp.setHeader("Allow", "GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS");
String headers = req.getHeader("Access-Control-Request-Headers");
String method = req.getHeader("Access-Control-Request-Method");
resp.addHeader("Access-Control-Allow-Methods", method);
resp.addHeader("Access-Control-Allow-Headers", headers);
if ("options".equalsIgnoreCase(req.getMethod()))
{
resp.setContentType("text/plain");
resp.getWriter().flush();
return;
}
}
// Fix ios6 caching post requests
if ("post".equalsIgnoreCase(req.getMethod())) {
resp.addHeader("Cache-Control", "no-cache");
}
if (filterChain != null) {
filterChain.doFilter(req, resp);
}
shouldAllowCorsOnOrigin is false, so the code does not enter to the large if.
Any ideas why the exception happens?

I would get the version number of Tomcat and look up the source code for DefaultServlet for that version. I looked up 6.0.26, but the line number in the stack trace doesn't coincide with a line that can throw this error.
The method in DefaultServlet that is throwing the error depends on resources obtained from either its own context or a JNDI lookup. Look further back in your logs for an exception with "No resources" as its message. There are two constants the DefaultServlet.init() method uses to look up resources -- does the server environment have resources for one of them?

You should look at indexpage servlet, probably there is a problem, because in your stacktrace, you have null pointer during Servlet.service() and this method is called by the servlet container to allow the servlet to respond to a request. Before of that init method is executed (at indexpage). Could you show us indexpage servlet?

Hide/handle servlet exception stack trace output

From this post I have thought of another question I cannot seem to find the answer to on the interweb.
I have a servlet filter which detects session timeouts and redirects to an error page. Due to my fledgling java I've used try catch blocks to catch exceptions and handle them gracefully, but in a session timeout situation, the context is invalid so I don't think I've got any code I can do that with which will stop the 'viewId could not be restored' stace trace appearing in my log even though I have a filter handling it.
How can I stop the exception trace from appearing in my log? It will be monitored autoamtically in live and it will be a false positive call out to the support team for this sort of error.
Any help appreciated.
EDIT
To be more clear, my code clip is currently
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
try {
chain.doFilter(request, response);
} catch (ServletException e) {
logger.error("Caught Servlet Exception");
Throwable rootCause = e.getRootCause();
logger.error("Root cause is " + rootCause.toString());
if (rootCause instanceof RuntimeException) { // This is true for any FacesException.
logger.error("Rethrowing exception as RuntimeException" + rootCause.toString());
throw (RuntimeException) rootCause; // Throw wrapped RuntimeException instead of ServletException.
} else {
throw e;
}
}
}
The log says:
|STDOUT| 2011-01-19 10:40:57,803 | ERROR | [http-8080-5]: Exception in the filter chain
javax.servlet.ServletException: viewId:/index.jsf - View /index.jsf could not be restored.
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:270)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
<snip>
at java.lang.Thread.run(Unknown Source)
Caused by: javax.faces.application.ViewExpiredException: viewId:/index.jsf - View /index.jsf could not be restored.
<snip>
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
... 21 more
19-Jan-2011 10:40:57 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet Faces Servlet threw exception
javax.faces.application.ViewExpiredException: viewId:/index.jsf - View /index.jsf could not be restored.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:185)
<snip>
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Unknown Source)
|STDOUT| 2011-01-19 10:40:57,803 | ERROR | [http-8080-5]: Caught Servlet Exception
|STDOUT| 2011-01-19 10:40:57,803 | ERROR | [http-8080-5]: Root cause is javax.faces.application.ViewExpiredException: viewId:/index.jsf - View /index.jsf could not be restored.
|STDOUT| 2011-01-19 10:40:57,803 | ERROR | [http-8080-5]: Rethrowing exception as RuntimeExceptionjavax.faces.application.ViewExpiredException: viewId:/index.jsf - View /index.jsf could not be restored.
As you can see from the code, I've caught the servlet exception in the filter, but the stack is still appearing in the log.
NEXT EDIT
The complete list of filters in my web.xml is as follows:
<filter>
<filter-name>Error</filter-name>
<filter-class>prismClient.ErrorFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Error</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter>
<display-name>RichFaces Filter</display-name>
<filter-name>richfaces</filter-name>
<filter-class>org.ajax4jsf.Filter</filter-class>
</filter>
<filter-mapping>
<filter-name>richfaces</filter-name>
<servlet-name>Faces Servlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>

Filters are executed in the order they are defined in the web.xml file. In your case, it looks like the jfaces filter is executed first and logging the stack trace before your custom filter has a chance to filter it out. Try making your filter entry in web.xml the first one.
EDIT
It's possible that some other filter in the chain is logging the ServletException before it throws it. In the stack trace you posted, it looks like there is a filter for ajax4jsf that may be logging the ServletException. Do you have the source for this? How may filters are in your web.xml?
EDIT 2
It looks like ajax4jsf is catching ServletException and logging an error message before throwing it back out. I suggest you get the source for the version of ajax4jsf that you're using and look at the lines in the stack trace (BaseXMLFilter.java line 178 and BaseFilter.java line 290) and search for logging statements. If you find them, you can either remove them from the source and rebuild ajax4jsf, or disable the category in your logging configuration file. I don't recommend the latter, because you will miss other errors that may occur in the filter.
If that is not the source of the error message, then I'm afraid I've run out of ideas.

Possibly because you rethrow the exception, whatever is logging it is still getting it. Even though you're blocking the ServletException out and rethrowing the RunTimeException (which ViewExpiredException is), something higher in the filter chain may be rewrapping it.
Do any of the logs you write in this method also show up in the log before the stacktrace?

Did you try writing a Session filter yourself? Find a nice example here.