[mule-user] Exception when using async soap msg with cxf

0 views
Skip to first unread message

Gerhard Maree

unread,
Oct 1, 2008, 11:09:41 AM10/1/08
to us...@mule.codehaus.org

Hi

I have WSDL which defines an asynchronous message. The port type and
wsdl operation do not define any output as in the following extract:

<wsdl:portType name="RequestInbound">
<wsdl:operation name="RequestInbound">
<wsdl:input message="p1:p1.PickingRequestIn" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="RequestInboundBinding" type="p1:
RequestInbound" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" />
<wsdl:operation name="RequestInbound">
<soap:operation
soapAction="http://sap.com/xi/WebService/soap1.1"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" />
<wsdl:input>
<soap:body use="literal"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" />
</wsdl:input>
</wsdl:operation>
</wsdl:binding>


When I use this WSDL to create a SOAP service using cxf wsdl2java it
creates a class with a @OneWay annotatation for the method.

@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@Oneway
@WebMethod(operationName = "RequestInbound", action =
"http://sap.com/xi/WebService/soap1.1")
public void requestInbound(
@WebParam(partName = "RequestIn", name = "RequestIn",
targetNamespace = "urn:pnp:eiss:im")
RequestIn requestIn
);


I have my service defined as follows:

<service name="DeliveryRequestService">

<inbound>
<inbound-endpoint
address="cxf:http://localhost:8777/esb/DeliveryRequestService"
synchronous="true"/>
</inbound>
<component>
<singleton-object class="request.RequestInboundImpl" />
</component>
</service>

When I call the webservice, the method runs but while writing the
reponse back to the client I get the following exception:
[10-01 15:36:22] ERROR DefaultExceptionStrategy
[connector.http.0.receiver.2]: Caught exception in Exception Strategy:
null
java.lang.NullPointerException
at
org.mule.transport.cxf.CxfServiceComponent$1.write(CxfServiceComponent.j
ava:272)
at
org.mule.transport.http.HttpServerConnection.writeResponse(HttpServerCon
nection.java:281)
at
org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageRe
ceiver.java:189)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWor
ker(ThreadPoolExecutor.java:1061)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker
.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Unknown Source)

Mule sends a result back but the Content Type in the HTTP header is set
to text/plain. The sytem which sends the message expects it to be
text/xml and assumes the request failed.
I tried changing the endpoint to async but this causes a different
exception.

Does anyone know what I could be doing wrong?

Thanks
Gerhard

Read our disclaimer at: http://www.picknpay.co.za/pnp/view/pnp/en/page5093?
If you don't have web access, the disclaimer can be mailed to you on request.
Disclaimer requests to be sent to it-se...@pnp.co.za

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


Antoine Borg

unread,
Oct 2, 2008, 5:39:52 AM10/2/08
to us...@mule.codehaus.org
Hmm ..

Not sure why the response is being returned as text/plain rather than
text/xml but perhaps a response transformer that removes the "text/plain"
and adds "text/xml" may be a suitable workaround.

The message properties transformer would be suitable:
http://mule.mulesource.org/display/MULE2USER/Transformers+Configuration+Refe
rence#TransformersConfigurationReference-Messagepropertiestransformer

HTH


Antoine Borg, Senior Consultant | Tel: +32 28 504 696
ricston Ltd., BP 2, 1180 Uccle, Brussels, BELGIUM
email: antoin...@ricston.com | blog: blog.ricston.com | web: ricston.com

Gerhard Maree

unread,
Oct 2, 2008, 8:00:32 AM10/2/08
to us...@mule.codehaus.org


Thanks Antoine!

Adding the correct content type as a message prperty to the transport
fixed that the problem. I still get the exception, but it seems that I
can ignore that.

Reply all
Reply to author
Forward
0 new messages