[ 
https://issues.apache.org/jira/browse/CXF-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13713606#comment-13713606
 ] 

Donatas Ciuksys commented on CXF-3836:
--------------------------------------

Please reopen this bug, there is a regression in CXF 2.7.5.
We recently got:

Caused by: java.lang.NullPointerException at 
lt.asseco.iaps.ws.bookingservice.CreateBookingResponse_WrapperTypeHelper1.createWrapperObject(Unknown
 Source)
        at 
org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:101)
        ... 54 more

The reason: supplying NULL to Holder OUT parameter. 

                
> Missing output parameters in wrapped method implementations generate NPE
> ------------------------------------------------------------------------
>
>                 Key: CXF-3836
>                 URL: https://issues.apache.org/jira/browse/CXF-3836
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 2.3.6, 2.4.2
>            Reporter: Scott S. McCoy
>            Assignee: Freeman Fang
>             Fix For: 2.3.8, 2.4.5, 2.5.1
>
>
> When implementing an interface generated from a WSDL which has an output 
> parameter stored in a holder, as in
> {code}
>         @WebParam(mode = WebParam.Mode.OUT, name = "created", targetNamespace 
> = "")
>         javax.xml.ws.Holder<java.lang.Boolean> created
> {code}
> Failing to provide a value in the supplied holder results in an NPE, 
> originating from the runtime-generated WrapperTypeHelper class, e.g.
> {code}
> java.lang.NullPointerException
>       at 
> com.vindicia.soap.v3_6.account.UpdateResponse_WrapperTypeHelper1.createWrapperObject(Unknown
>  Source)
>       at 
> org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:105)
> {code}
> This fails to inform the user of the cause of the issue or how to diagnose 
> it.  Instead, required parameters should be validated to atleast be not null 
> before they are assumed to have been provided.
> I have validated this behavior on 2.4.2, 2.4.0 and 2.3.6.
> The work-around for the user is of course to provide a non-null value in the 
> holder object.
> It is worth noting this appears to only happen for output parameters that are 
> normally mapped to primitive types.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to