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

Amichai Rothman commented on CXF-6737:
--------------------------------------

The method in this test project takes no arguments and returns void, so I don't 
think it's related to parameter naming.

Putting a breakpoint in ReflectionServiceFactoryBean.initializeWSDLOperation 
and following the code flow through these 3 methods in the class (as described 
above) appears to point at mis-handling the return type, I think. Maybe it 
shouldn't be calling initializeParameter at all on a void return type? Or void 
should be handled differently within initializeParameter? (btw, it's indeed 
confusing that a method called initializeParameter is being invoked for the 
return type and not only parameters)


> ClientProxyFactoryBean doesn't work with void methods
> -----------------------------------------------------
>
>                 Key: CXF-6737
>                 URL: https://issues.apache.org/jira/browse/CXF-6737
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.1.1
>         Environment: DOSGi 1.7.0
>            Reporter: Amichai Rothman
>         Attachments: bad_client_example.diff
>
>
> I'm trying to use a simple ClientProxyFactoryBean to connect to a 
> dosgi-exported service. Without specifying the wsdl url, it doesn't work 
> since apparently the method argument names don't match (arg0 vs actual 
> parameter name, as explained in CXF-897), so I added the wsdl url. Now 
> service methods that have a return value seem to work ok, but those with void 
> return type do not.
> Further investigation suggests that the issue might be in 
> ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning 
> (no method for op) instead of binding the operation, because 
> initializeClassInfo returns false, because initializeParameter called with 
> the return type (near the bottom of initializeClassInfo) returns false, since 
> o.getOutput().getMessagePart/getMessagePartByIndex return null (since there 
> are no parts - the method can throw an exception, for which the output 
> message exists, but there is no actual return type).
> A quick test in the debugger shows that if I manipulate the flow manually 
> (e.g. execute the if caluse in initializeWSDLOperation after 
> initializeClassInfo returns) then the method invocation works ok.
> I am not familiar with the inner workings of WSDL or these classes, so I'm 
> not sure what is the correct place to apply a fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to