You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by easternwahoo <ja...@siemens.com> on 2010/05/24 16:44:40 UTC
Error handling for invalid Soap body content
On occasion, our web services clients may send us garbage messages. For
example, the message may consist of a valid soap envelope, but the soap body
is empty. On other occasions, the soap body contains non-xml content.
CXF gets nullpointer exceptions in these cases, and returns a generic Soap
fault, "Fault occurred while processing". Shouldn't the framework be able
to provide a more useful message, such as "malformed xml content", and not
fail on a nullpointer exception? We're using CXF 2.2.6.
Below is a stack trace generated for a Soap Envelope containing an empty
body: <soapenv:Header/>
<soapenv:Body></soapenv:Body>
WARNING: Interceptor {http://hello.com/soarian/hello_v1}Hello_v1Servicehas
thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispatcher.java:96)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:57)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
at
org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
at
org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
View this message in context: http://old.nabble.com/Error-handling-for-invalid-Soap-body-content-tp28657740p28657740.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Error handling for invalid Soap body content
Posted by easternwahoo <ja...@siemens.com>.
OK thanks, I've created https://issues.apache.org/jira/browse/CXF-2824
dkulp wrote:
>
>
> When you encounter such cases, please log a JIRA at:
> https://issues.apache.org/jira/browse/CXF
> Most of the time, we can just add an NPE guard or something there to
> produce
> a better error message. For invalid XML, we sometimes have issues
> trying to
> detect that depending on the error messages that the parser provides, but
> if
> there is a JIRA (with preferably a test case), we can at least look and
> try.
>
> Dan
>
>
>
> On Monday 24 May 2010 10:44:40 am easternwahoo wrote:
>> On occasion, our web services clients may send us garbage messages. For
>> example, the message may consist of a valid soap envelope, but the soap
>> body is empty. On other occasions, the soap body contains non-xml
>> content.
>>
>> CXF gets nullpointer exceptions in these cases, and returns a generic
>> Soap
>> fault, "Fault occurred while processing". Shouldn't the framework be
>> able
>> to provide a more useful message, such as "malformed xml content", and
>> not
>> fail on a nullpointer exception? We're using CXF 2.2.6.
>>
>> Below is a stack trace generated for a Soap Envelope containing an empty
>> body: <soapenv:Header/>
>> <soapenv:Body></soapenv:Body>
>>
>>
>> WARNING: Interceptor
>> {http://hello.com/soarian/hello_v1}Hello_v1Servicehas
>> thrown exception, unwinding now
>> java.lang.NullPointerException
>> at
>> org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispat
>> cher.java:96) at
>> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:
>> 57) at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerIn
>> terceptor.java:58) at
>> java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at
>> java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>> at java.util.concurrent.FutureTask.run(Unknown Source)
>> at
>> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.ja
>> va:37) at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceI
>> nvokerInterceptor.java:106) at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
>> n.java:243) at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
>> bserver.java:109) at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jet
>> tyHTTPDestination.java:312) at
>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTT
>> PDestination.java:276) at
>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandle
>> r.java:70) at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>> at
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCol
>> lection.java:230) at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>> at org.mortbay.jetty.Server.handle(Server.java:326)
>> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
>> at
>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java
>> :930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
>> at
>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409
>> ) at
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:58
>> 2)
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
>
--
View this message in context: http://old.nabble.com/Error-handling-for-invalid-Soap-body-content-tp28657740p28658336.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Error handling for invalid Soap body content
Posted by Daniel Kulp <dk...@apache.org>.
When you encounter such cases, please log a JIRA at:
https://issues.apache.org/jira/browse/CXF
Most of the time, we can just add an NPE guard or something there to produce
a better error message. For invalid XML, we sometimes have issues trying to
detect that depending on the error messages that the parser provides, but if
there is a JIRA (with preferably a test case), we can at least look and try.
Dan
On Monday 24 May 2010 10:44:40 am easternwahoo wrote:
> On occasion, our web services clients may send us garbage messages. For
> example, the message may consist of a valid soap envelope, but the soap
> body is empty. On other occasions, the soap body contains non-xml content.
>
> CXF gets nullpointer exceptions in these cases, and returns a generic Soap
> fault, "Fault occurred while processing". Shouldn't the framework be able
> to provide a more useful message, such as "malformed xml content", and not
> fail on a nullpointer exception? We're using CXF 2.2.6.
>
> Below is a stack trace generated for a Soap Envelope containing an empty
> body: <soapenv:Header/>
> <soapenv:Body></soapenv:Body>
>
>
> WARNING: Interceptor {http://hello.com/soarian/hello_v1}Hello_v1Servicehas
> thrown exception, unwinding now
> java.lang.NullPointerException
> at
> org.apache.cxf.frontend.SimpleMethodDispatcher.getMethod(SimpleMethodDispat
> cher.java:96) at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:
> 57) at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerIn
> terceptor.java:58) at
> java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at
> java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.ja
> va:37) at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceI
> nvokerInterceptor.java:106) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
> bserver.java:109) at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jet
> tyHTTPDestination.java:312) at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTT
> PDestination.java:276) at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandle
> r.java:70) at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCol
> lection.java:230) at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:326)
> at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java
> :930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409
> ) at
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:58
> 2)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog