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

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

After applying the patch with the suggested fix, the sample project (example 3) 
works flawlessly when setting the flag to use jaxb, and when setting it to 
aegis it works correctly the first time, and gives an exception on subsequent 
invocations - but the latter seems to be unrelated, perhaps it's triggering 
CXF-2548.

> 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, bad_client_example.diff, 
> bad_client_example3.diff, fix_void_method.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