Ah.  OK.  I think I understand now....

One "restriction" is likely that the Response object must really be the real 
Response object that the runtime would be using for the non async case.   
When you generate code with wsdl2java, that's easy as the code generator 
would have stuck an appropriate @ResponseWrapper annotation on the sync 
method that would match the exact class that is used for the async method.   
Most likely, if your response object is completely correct, if you add that 
annotation to your sync method, it would have worked.   It would not have 
had to generate the 'jaxws_asm' version at runtime to use.

Dan


On Thursday, May 17, 2012 10:41:47 PM jerryscott2012 wrote:
> Daniel:
> 
>       thank's a lot for your reply.
> 
>       I noticed that once I dropped the  @UseAsyncMethod I could make use
> of the JaxWsProxyFactoryBean to access the interface published, by the
> way the program for client accessing was mainly based apache cxf 2.5.2.
> 
>      and while I continued to test the async call to the specialized
> interface like reqForCardServiceAsync, some
> strange thing occured that the "ReqForCardServiceResponse" returned
> produced based the javaws_asm way,
> so such could not be directly cast to the orignal class(for example the
> ReqForCardServiceResponse produced like
> com.yilnk.card.ws.service.ReqForCardServiceResponse  but in runtime the
> actual class returned was
> com.yilnk.card.ws.service.javaws_asm.ReqForCardServiceResponse).
> 
>       I tried to look up some ways to solve the problem above but none
> couldn't help profit as the server side did not
> throw any exception. so as I mentioned and concluded that  @UseAsyncMethod
> might be not match with the
> JaxWsProxyFactoryBean  way to access the published interface(for while I
> use wsdl2java command to generate the
> client or server classes) and also it might produced the javaws_asm
> runtime mistake once I use the XXResponse way
> to get the result from server side.
> 
>      great appreciate that cxf team could help to point out the
> mistake(the client accessing way or jars configured not properly of the
> proxy accessing way has its limitation to access the async call).
> 
>      Best wishes.
> 
> jerryscott
> 
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Async-call-with-cxf-but-IllegalStateExcep
> tion-tp5707881p5708069.html Sent from the cxf-user mailing list archive at
> Nabble.com.
-- 
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply via email to