Thanks for your feedback. Unfortunately, I have a requirement to make the
endpoint one-way synchronous. I actually go through an ESB and I want the
client call to the ESB to be asynchronous. By having the endpoint be
synchronous, I can take advantage of the re-try functionality. Going
asynchronously through the ESB allows the call to be processed without
forcing the client to wait for the processing.


Freeman Fang wrote:
> 
> Hi,
> 
> For your case, I think you shouldn't use Oneway.
> If you can modify the wsdl, what I can come up with is that you can  
> use something like the return type is void, but the method can throw  
> exception.
> 
> In this case, the response message shouldn't be null, it should be  
> empty, so you can't remove out message from wsdl, please take a look  
> the "pingMe" method defined in hello_world.wsdl(this is quite popular  
> used in cxf kit example), the schema for pingMeResponse element just  
> like
>       <element name="pingMeResponse">
>                  <complexType/>
>              </element>
> the pingMeResponse is here but it's empty, also the generated method  
> signature is
> @RequestWrapper(localName = "pingMe", targetNamespace =
> "http://apache.org/hello_world_soap_http/types 
> ", className = "org.apache.hello_wo
> rld_soap_http.types.PingMe")
>      @ResponseWrapper(localName = "pingMeResponse", targetNamespace =
> "http://apache.org/hello_world_soap_http/types 
> ", className = "org.apache
> .hello_world_soap_http.types.PingMeResponse")    @WebMethod
>      public void pingMe() throws PingMeFault;
> 
> This method isn't oneway as it still can return exception, so it's  
> handled synchronously.
> 
> Freeman
> 
> 
> On 2009-12-29, at 下午11:51, cplin wrote:
> 
>>
>> I'm trying to configure a JMS web service endpoint that is one-way.  
>> The WSDL
>> definition for the endpoint has a request message part and does NOT  
>> have a
>> response message part. However, I still want to be able to leverage  
>> the JMS
>> re-try functionality. Digging into the CXF framework, I see that the
>> OneWayProcessorInterceptor will automatically spawn a new thread  
>> (handles
>> the request asynchronously) if the endpoint is one way. Since it is
>> processed asynchronously, any exceptions (that would trigger retry  
>> when
>> session transacted) would be part of the asynchronous thread, not  
>> the JMS
>> handling thread, so the retry is never triggered.
>>
>> Is there a way to have a synchronous one-way (realizing that it is a  
>> bit of
>> a contradiction) or is there a better approach with the CXF framework?
>> Ultimately, I'm just trying to leverage the JMS retry functionality  
>> for a
>> asynchronous web service operation that should be re-tried on failure.
>> -- 
>> View this message in context:
>> http://old.nabble.com/Synchronous-One-Way-tp26956147p26956147.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
> 
> 
> -- 
> Freeman Fang
> ------------------------
> Open Source SOA: http://fusesource.com
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Synchronous-One-Way-tp26956147p26967207.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to