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.
Related
I have a simple route:
public class PartnerRoute extends SpringRouteBuilder
{
#Value("${comm.async.req.incoming.queue}")
private String reqInputQueue;
#Override
public void configure() throws Exception
{
onException(Exception.class)
.to("activemq:queue:wrongMessages");
from("cxf:bean:partnerService")
.log("PartnerData arrived")
.to("activemq:queue:" + reqInputQueue);
}
}
As you see, the start point is a CXF webservice.
The WS defined in camel-context.xml
<cxf:cxfEndpoint id="partnerService"
address="http://${comm.host}:${comm.port}/cxf/PartnerService"
serviceClass="esb.ws.partner.service.PartnerService" />
I would like to handling the CXF exception. (Someone calls the WS with wrong data.)
I have got this error, when I call the WS with wron structure:
2015-02-26 16:16:44,901 | WARN | org.apache.cxf.phase.PhaseInterceptorChain | org.apache.cxf.cxf-api | (LogUtils.java:452) | Interceptor for {http://service.partner.ws.esb.ivir.tsm.hu/}PartnerServiceService#{http://service.partner.ws.esb.ivir.tsm.hu/}startMessageProcessing has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element (uri:"", local:"messageFilterx"). Expected elements are <{}messageFilter>,<{}hash>,<{}priority>,<{}referenceNumber>,<{}responseRequired>,<{}requestDate>,<{}messageType>,<{}consumer>,<{}requestor>
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:881)[139:org.apache.cxf.cxf-rt-databinding-jaxb:2.7.11]
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:702)[139:org.apache.cxf.cxf-rt-databinding-jaxb:2.7.11]
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:160)[139:org.apache.cxf.cxf-rt-databinding-jaxb:2.7.11]
at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:192)[135:org.apache.cxf.cxf-api:2.7.11]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)[135:org.apache.cxf.cxf-api:2.7.11]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)[135:org.apache.cxf.cxf-api:2.7.11]
at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)[157:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.11]
at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)[157:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.11]
at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:65)[157:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.11]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1024)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.Server.handle(Server.java:370)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[63:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
at java.lang.Thread.run(Thread.java:744)[:1.7.0_51]
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"messageFilterx"). Expected elements are <{}messageFilter>,<{}hash>,<{}priority>,<{}referenceNumber>,<{}responseRequired>,<{}requestDate>,<{}messageType>,<{}consumer>,<{}requestor>]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:425)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at org.apache.cxf.jaxb.JAXBEncoderDecoder.doUnmarshal(JAXBEncoderDecoder.java:842)[139:org.apache.cxf.cxf-rt-databinding-jaxb:2.7.11]
at org.apache.cxf.jaxb.JAXBEncoderDecoder.access$100(JAXBEncoderDecoder.java:101)[139:org.apache.cxf.cxf-rt-databinding-jaxb:2.7.11]
at org.apache.cxf.jaxb.JAXBEncoderDecoder$2.run(JAXBEncoderDecoder.java:870)
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_51]
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:868)[139:org.apache.cxf.cxf-rt-databinding-jaxb:2.7.11]
... 25 more
Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"messageFilterx"). Expected elements are <{}messageFilter>,<{}hash>,<{}priority>,<{}referenceNumber>,<{}responseRequired>,<{}requestDate>,<{}messageType>,<{}consumer>,<{}requestor>
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:642)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:254)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:249)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:116)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement(Loader.java:101)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement(StructureLoader.java:243)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:478)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:459)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:242)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:176)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360)[84:org.apache.servicemix.bundles.jaxb-impl:2.2.1.1_2]
... 31 more
Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"messageFilterx"). Expected elements are <{}messageFilter>,<{}hash>,<{}priority>,<{}referenceNumber>,<{}responseRequired>,<{}requestDate>,<{}messageType>,<{}consumer>,<{}requestor>
... 42 more
I set up the "onException" but nothing happened.
Could you help, how can I handling that exception?
Thank you!
Feri
Its a chicken and egg situation. Camel's error handler using onException or errorHandler is during routing. But that entails the consumer is able to accept the incoming message and create a Camel Exchange instance and start route the message.
From the stracktrace this is not the case, as Apache CXF fails to do so. Some Camel components support bridging from the consumer errors to Camel error handler using consumer.bridgeErrorHandler=true option. Not sure if that is the case with CXF.
If you don't want the Exception to go any further, you need to mark it as handled.
onException(Exception.class)
.handled(true)
.to("activemq:queue:wrongMessages");
Until now we used JBoss AS 7.1 which has a tomcat as front-server. We now upgraded to Wildfly (JBoss 8.0) which ships with undertow as a tomcat replacement.
For our filedownloads, we are reading the input stream of the file, and writing this to the external context's response output stream. This worked well in JBoss AS 7.1 - even for large files. In Undertow WE receive the following exception even for pretty "small" files:
13:04:43,292 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /project/getFile.xhtml}: java.lang.RuntimeException: org.xnio.channels.FixedLengthOverflowException
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: org.xnio.channels.FixedLengthOverflowException
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:97)
at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:137)
at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:172)
at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:580)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:614)
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
... 9 more
The getFile.xhtml is invoking the download and the following code is used to copy the stream:
(Try, catch, logs and error handling removed to save some space)
public void downloadFile(FileEntity fileEntity) {
FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
ec.responseReset();
ec.setResponseContentType(getMimeType(fileEntity.getFile()));
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
ec.setResponseHeader("Content-Disposition", "attachment; filename=\"" + ConversionHelper.validateFilename(fileEntity.getDisplayFileName()) + "\"");
OutputStream output = ec.getResponseOutputStream();
FileInputStream fis = new FileInputStream(fileEntity.getFile());
IOUtils.copy(fis, output);
fc.responseComplete();
}
I noticed that removing the line
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
makes it work again. However the ResponseConentLength is "correct". Using
ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue() + 9);
(note the +9) solves this. Using +8 -> FixedLengthOverflow, using +10 -> FixedLengthUnderflow
The +9 is independent of the filesize. Any idea? Looks strange to me...
If you call output.close() it should have the effect you are after. This looks like an issue with JSF, and not related to Undertow.
Found the problem.
It has to do with the change of the server engine. Just not sure if it is directly related to undertow, or more an error with wildfly / JSF (or if it was an error in Jboss and now is working correctly):
To invoke the download, we used something like this in the getFile.xhtml:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
</f:metadata>
<h:outputLabel value="#{getFileController.download()}" />
this would usually produce:
<label>value</label>
if the value of the label would be a string.
since we reset the response inside download(), <label> is removed again. Then, using a fixed response size that's equal the file-length and calling responseComplete() basically ommits the trailing </label>. Undertow however seems to ignore the responseComplete()-Call and tries to append </label> to the response, notices, that the end of the (fixed) response stream is reached, and therefore throws the mentioned exception.
That's why providing a size of +9 solves this error - but causes corrupt files, cause </label>\n will be appended to the file.
obviously the usage of an output label was bad practice there. But since we reseted and manually filled the response stream and called responseComplete() that was working fine.
the fix is obviously to not produce any (not required) html tags on that page:
<f:metadata>
<f:viewParam name="fileId" required="true"
value="#{getFileController.fileId}"></f:viewParam>
<f:event listener="#{getFileController.dlNow()}" type="preRenderView"></f:event>
</f:metadata>
Beside the bad design there - shouldn't call responseComplete() ommit any additional writing to the response stream, including any write ATTEMPTS?
The docu says:
Signal the JavaServer Faces implementation that the HTTP response for
this request has already been generated (such as an HTTP redirect),
and that the request processing lifecycle should be terminated as soon
as the current phase is completed.
So, if the Faces Implementation is told that the Response has been send - why would it try to append something?
I am running two axis2 services which communicate with each other. On every service startup I get this error:
2014-02-24 13:02:31,258 [INFO ] HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:621)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:193)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:404)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:231)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:443)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:406)
at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:446)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Since this error is not important, I would like to catch it and to print some better error message instead of the whole stack trace. Where do I catch this error?
Looking at the stack trace, I don't think you can catch it. Catching it would require that you own code somewhere in the Thread where the exception is being thrown.
Looking at the lowest stack in the trace shows this:
at java.lang.Thread.run(Thread.java:724)
To me this says that the exception is occurring in a thread most likely started by Axis. Because of this you can't catch it and show an error message.
If this is expected behavior, the best you can do is to configure your logging framework not to show INFOs from Axis. Be aware that this may mean you'll also miss more useful error messages as well.
All in all, I would focus on how to solve the "Unable to sendViaPost" from happening rather than suppressing the logging statement.
To answer your comment question: As you can see from the stack trace, the exception is not caught by any client code but is bubbled up to Thread itself. This is the stopping point for an Exception and where it stops. If you were going to catch it you'd have to have code in its call stack (which you don't, since when the thread is created by Axis a new call stack is created for the new thread Axis starts).
Read more here. The only difference in your case is that since the exception is not thrown on the main thread the program doesn't exit, but the thread where the exception occurs is terminated.
To sum it up: You have no code in the call stack and therefore cannot catch the exception. The only other option is to turn of INFO statements for Axis.
If I am understanding the question properly you're attempting to catch something that is not the exception that is being thrown.
This:
HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
is what is being attempted. When it failed it's throwing a ConnectException.
Which you can simply catch with
try{
//Code that Makes the Connection
}
catch (ConnectException e)
{
e.printStackTrace();//Or What ever your message may be
}
Without seeing some code it's impossible to give a definitive answer. But this likely will solve the problem.
One Caveat, if you do catch a ConnectException to suppress it, you could suppress when there actually is a problem that would also throw a ConnectException.
If this is happening when you are starting up the server you might want to check why this is happening before trying to suppress it.
If it's refusing the connection that you are attempting you might want to ensure where it is connecting to has an available socket to connect to.
2014-02-24 13:02:31,258 [INFO] HTTPSender - Unable to
sendViaPost to
url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
Well, if you look closely, the message which you are trying to catch isn't an ERROR at all. It's an INFO log generated from HTTPSender. Only thing which you should catch in this entire stacktrace is java.net.ConnectException and check for message Connection refused.
You can make it easier for your clients though and provide a message, by wrapping the java.net.ConnectException with message Connection refused or throwing a custom exception with the original exception as the cause.
UPDATE
java.net.ConnectException is an elementary exception in network transactions. Generally standard libraries do not catch them unless there is something specific to be done.
In this case, if you are unable to catch hold of java.net.ConnectException, then you can look out to catch AxisFault thrown by org.apache.axis2.description.OutInAxisOperationClient.send.
Below snippet may be useful for you.
try {
...
} catch (RemoteException ex) {
if(ex instanceof AxisFault){
logger.error("Axis Fault error: " + ((AxisFault)ex).getFaultString());
throw new CustomExcpetion(" Custom Message ");
}
}
Also note that AxisFault is a subclass of java.rmi.RemoteException and this will not get caught when you use java.lang.Exception in a catch statement.
Shishir
As part of an application, we have a JSP page (parent page) in which we are calling another JSP page (child page), where all the parameters of the child page has been assigned to the form of the parent page and then trying to submit the page.
At the time of submission, we are getting the following error on the frontend...
(I) Front end error
=====================
Error 500--Internal Server Error
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
And on the backend we get the following error...
(II) Application server Error log
<Error> <HTTP> <BEA-101019> <[ServletContext(id=29607640,name=test,c
ontext-path=/Test)] Servlet failed with IOException
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at weblogic.servlet.internal.PostInputStream.read(PostInputStream.java:170)
at weblogic.servlet.internal.ServletInputStreamImpl$1.read(ServletInputStreamImpl.java:115)
at weblogic.servlet.internal.ServletInputStreamImpl.read(ServletInputStreamImpl.java:180)
at weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:1339
)
at weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:120
6)
at weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:1409)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:446)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:39
02)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
**--------------- nested within: ------------------
weblogic.utils.NestedRuntimeException: Cannot parse POST parameters of request: '/Test/test1.jsp
' - with nested exception:
[java.net.SocketTimeoutException: Read timed out]**
at weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:1364
)
at weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:120
6)
at weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:1409)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:446)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:348)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:7047)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:39
02)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2773)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
Could you please offer a suggestion as to the cause of the problem.
You are getting a SocketTimeoutException, so there is probably something wrong with your POST. For example, you might not be sending through enough bytes of data, or you might not be closing off the connection once you're finished with it - basically its sitting there waiting for more information until it eventually times out.
Could you please post some of your JSP code, especially where you're creating and running your POST, so that we can provide some better feedback.
If my code throws an exception, sometimes - not everytime - the jsf presents a blank page. I´m using facelets for layout.
A similar error were reported at this Sun forumn´s post, but without answers.
Anyone else with the same problem, or have a solution?
;)
Due to some requests. Here follow more datails:
web.xml
<error-page>
<exception-type>com.company.ApplicationResourceException</exception-type>
<location>/error.faces</location>
</error-page>
And the stack related to jsf is printed after the real exception:
####<Sep 23, 2008 5:42:55 PM GMT-03:00> <Error> <HTTP> <comp141> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1222202575662> <BEA-101107> <[weblogic.servlet.internal.WebAppServletContext#6d46b9 - appName: 'ControlPanelEAR', name: 'ControlPanelWeb', context-path: '/Web'] Problem occurred while serving the error page.
javax.servlet.ServletException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:249)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:525)
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:261)
at weblogic.servlet.internal.ForwardAction.run(ForwardAction.java:22)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(Unknown Source)
at weblogic.servlet.internal.ErrorManager.handleException(ErrorManager.java:144)
at weblogic.servlet.internal.WebAppServletContext.handleThrowableFromInvocation(WebAppServletContext.java:2201)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2053)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
javax.faces.application.ViewExpiredException: viewId:/error.xhtml - View /error.xhtml could not be restored.
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
I´m using the jsf version Mojarra 1.2_09, richfaces 3.2.1.GA and facelets 1.1.13.
Hope some help :(
I think this largely depends on your JSF implementation. I've heard that some will render blank screens.
The one we were using would throw error 500's with a stack trace. Other times out buttons wouldn't work without any error for the user. This was all during our development phase.
But the best advice I can give you is to catch the exceptions and log them in an error log so you have the stack trace for debugging later. For messages that we couldn't do anything about like a backend failing we would just add a fatal message to the FacesContext that gets displayed on the screen and log the stack trace.
I fixed a similar problem in my error.jsp page today. This won't be exactly the same as yours, but it might point someone in the right direction if they're having a similar problem. My problem seemed to be coming from two different sources.
First, the message exception property wasn't being set in some of the servlets that were throwing exceptions caught by the error page. The servlets were catching and rethrowing exceptions using the ServletException(Throwable rootCause) constructor.
Second, in the error page itself, the original author had used scriptlet code to parse the message using String.split(message, ";"); Since the message was null this failed. I was getting a NullPointerException in my error log, along with the message "Problem occurred while serving the error page."
These two things combined to give me a blank page at the URL of the servlet that was throwing the original exception. I fixed my problem by providing my own error message when I rethrow exceptions in my servlets using the ServletException(String message, Throwable rootCause) constructor, so the error message will no longer be null. I also rewrote the error.jsp page using EL instead of scriptlet code, but that wasn't strictly necessary.
For a blank page on JSF 2, place a breakpoint in ExceptionHandlerWrapper.handle or a class overriding this method. In my case it was due to custom code which was a too restrictive and the error was not logged.