[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373150#comment-16373150
]
Colm O hEigeartaigh commented on CXF-7653:
------------------------------------------
I could reproduce the NPE with a testcase locally. It's possible to get further
with setting the parameters List on the message in the DocLiteralInInterceptor,
but you keep on running into NPEs after that. I got as far as:
java.lang.NullPointerException
at com.sun.proxy.$Proxy55.doubleIt(Unknown Source)
> Null pointer in JaxwsResponseCallback
> -------------------------------------
>
> Key: CXF-7653
> URL: https://issues.apache.org/jira/browse/CXF-7653
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 3.0.10
> Environment: AIX
> Reporter: Neal Johnson
> Priority: Major
>
> Occasionally we'll get a null pointer in the JAXWS code.
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.jaxws.JaxwsResponseCallback.get(JaxwsResponseCallback.java:49)
> When we receive a SOAP message with an empty body (example below) the
> (T)callback.get()[0] line in JaxwsResponseCallback throws a null pointer
> exception. We're still unsure why we're getting a message with an empty body
> in the first place, and if that's AIX related or we're just lucky in other
> operating systems.
> {{<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";>}}
> {{ <soap:Header>}}
> {{ <!-- Stuff in here that I've removed. -->}}
> {{ </soap:Header>}}
> {{ <soap:Body />}}
> {{</soap:Envelope>}}
> We did some debugging and checked where our code diverged between the two
> types of messages. The below chunk of code is where it starts to unravel.
> {code:java|title=Code from within
> DocLiteralInInterceptor.java|borderStyle=solid}
> MessageContentsList parameters = new MessageContentsList();
> Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.getBindingOperationInfo();
> boolean client = isRequestor(message);
> //if body is empty and we have BindingOperationInfo, we do not need to match
> //operation anymore, just return
> if (bop != null && !StaxUtils.toNextElement(xmlReader)) {
> // body may be empty for partial response to decoupled request
> return;
> }
> ...
> // Lots of logic
> ...
> message.setContent(List.class, parameters);
> {code}
> ~~~~~~~
> When we do a StaxUtils.toNextElement that returns false, as it hits the end
> of the body immediately. This causes it to return without setting the
> MessageContentsList as a list on the message. Later, when the code tries to
> do a .getContent(List) it doesn't find anything, and this leads to it setting
> null as the first element returned on callback.get()[0].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
