[
https://issues.apache.org/jira/browse/CXF-7653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373890#comment-16373890
]
Daniel Kulp commented on CXF-7653:
----------------------------------
If the WSDL for the operation states that the body should have content, than an
exception should be thrown. Probably some sort of validation exception or
IllegalArguementException or something. An NPE is probably not ideal, or if
it is an NPE, at least put a better description in the message.
> 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)
