[
https://issues.apache.org/jira/browse/AXIS2-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen resolved AXIS2-5773.
------------------------------------
Resolution: Incomplete
The RequestResponseTransport.TRANSPORT_CONTROL property is set in
createMessageContext. If it is no longer present after the execution of the
request, then something weird is going on in your service implementation. If
you believe that there is a bug in Axis2 (and not something weird in your
service implementation), then please provide the necessary code to reproduce
the issue (with a recent Axis2 version) and reopen the bug.
> NullPointerException in AxisServlet when no RequestResponseTransport
> --------------------------------------------------------------------
>
> Key: AXIS2-5773
> URL: https://issues.apache.org/jira/browse/AXIS2-5773
> Project: Axis2
> Issue Type: Bug
> Components: transports
> Affects Versions: 1.6.4
> Environment: Tomcat 7.0.56, Debian 8.3, Java 1.7.0_95, Apache 2.4.10
> w/ ajp
> Reporter: Bastien
>
> Not sure how to describe this as it may be a configuration issue on my end,
> but I'm facing an error on Axis2 1.6.4 in the AxisServlet class, line 165
> with a NullPointerException when the code checks for the presence of a
> RequestResponseTransport in the current MessageContext.
> It occurs at the end of the service call being processed, when checking if
> the response has been written. By looking at the source file I suppose this
> is because the RequestResponseTransport.TRANSPORT_CONTROL has not been set.
> This seems to be confirmed by the presence of the following DEBUG level logs:
> DEBUG org.apache.axis2.transport.TransportUtils - Did not find
> RequestResponseTransport cannot set response written
> DEBUG org.apache.axis2.transport.TransportUtils - Did not find
> RequestResponseTransport returning false from getResponseWritten()
> The complete stacktrace is as follows:
> ERROR org.apache.axis2.transport.http.AxisServlet -
> java.lang.NullPointerException
> at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:165)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> One interesting thing is that it does not prevent my service (POJO based)
> from returning its response back to the client. However I do have a
> stacktrace at the container level when this occurs:
> GRAVE: Servlet.service() for servlet [AxisServlet] in context with path
> [/server] threw exception [org.apache.axis2.AxisFault: No transport info in
> MessageContext] with root cause
> org.apache.axis2.AxisFault: No transport info in MessageContext
> at
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingOutputStream(CommonsHTTPTransportSender.java:270)
> at
> org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:233)
> at org.apache.axis2.engine.AxisEngine.sendFault(AxisEngine.java:526)
> at
> org.apache.axis2.transport.http.AxisServlet.handleFault(AxisServlet.java:433)
> at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:216)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
> For what it's worth, I think that replacing the test on line 165 to check for
> null should be enough as the following:
> if (!TransportUtils.isResponseWritten(msgContext)
> && msgContext.getProperty(RequestResponseTransport.TRANSPORT_CONTROL)
> != null
> && (((RequestResponseTransport)
> msgContext.getProperty(
>
> RequestResponseTransport.TRANSPORT_CONTROL)).
> getStatus() != RequestResponseTransport.
>
> RequestResponseTransportStatus.SIGNALLED)) {
> But I have no idea if this would trigger any side effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
