[mule-user] Transparent WS forwarding - or avoiding the 'actor' attribute

42 views
Skip to first unread message

Jose Ignacio

unread,
Aug 31, 2011, 8:47:49 AM8/31/11
to us...@mule.codehaus.org
Hi,

I am forwarding a WS call, and I need to do it transparently. The server side is returning an error due to the 'actor' attribute that is inserted in the soap header by mule. The guys told me that the petition would work just by removing this attribute. Any way to do it? The service configuration is this:

<service name="firma-afirma" >
<inbound>
<cxf:inbound-endpoint connector-ref="clientWS-afirma" synchronous="true"
applyTransformersToProtocol="false"
enableMuleSoapHeaders="false"
applySecurityToProtocol="false"
address="http://${inbound.host}:${inbound.port}/services/FirmaService"
mtomEnabled="true" >
<cxf:inInterceptors>
<spring:bean class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
</cxf:inInterceptors>

</cxf:inbound-endpoint>
</inbound>

<component>
<spring-object bean="frontend" />
</component>

<outbound>
<pass-through-router>
<outbound-endpoint
address="wsdl-axis:https://${afirma.host}:${afirma.port}/afirmaws/services/ValidarFirma?wsdl"
synchronous="true" >
</outbound-endpoint>
</pass-through-router>

</outbound>
</service>


I have tried also this in the outbound part, but seems there is something missing in this setup:

<outbound>
<pass-through-router>
<cxf:outbound-endpoint
proxy="true"
enableMuleSoapHeaders="false"
address="wsdl-axis:https://${afirma.host}:${afirma.port}/afirmaws/services/ValidarFirma?wsdl"
synchronous="true" >
</cxf:outbound-endpoint>
</pass-through-router>

</outbound>


But with this I am getting an exception:


14:35:43,399 ERROR [connector.http.0.receiver.6] org.mule.service.DefaultServiceExceptionStrategy -
********************************************************************************
Message : The endpoint "" is malformed and cannot be parsed. If this is the name of a global endpoint, check the name is correct, that the endpoint exists, and that you are using the correct configuration (eg the "ref" attribute). Note that names on inbound and outbound endpoints cannot be used to send or receive messages; use a named global endpoint instead.
Type : org.mule.api.endpoint.MalformedEndpointException
Code : MULE_ERROR-64051
JavaDoc : http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/endpoint/MalformedEndpointException.html
********************************************************************************
Exception stack is:
1. The endpoint "" is malformed and cannot be parsed. If this is the name of a global endpoint, check the name is correct, that the endpoint exists, and that you are using the correct configuration (eg the "ref" attribute). Note that names on inbound and outbound endpoints cannot be used to send or receive messages; use a named global endpoint instead. (org.mule.api.endpoint.MalformedEndpointException)
org.mule.endpoint.MuleEndpointURI:137 (http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/endpoint/MalformedEndpointException.html)
********************************************************************************
Root Exception stack trace:
org.mule.api.endpoint.MalformedEndpointException: The endpoint "" is malformed and cannot be parsed. If this is the name of a global endpoint, check the name is correct, that the endpoint exists, and that you are using the correct configuration (eg the "ref" attribute). Note that names on inbound and outbound endpoints cannot be used to send or receive messages; use a named global endpoint instead.
at org.mule.endpoint.MuleEndpointURI.<init>(MuleEndpointURI.java:137)
at org.mule.endpoint.URIBuilder.getEndpoint(URIBuilder.java:173)
at org.mule.endpoint.AbstractEndpointBuilder.getProperties(AbstractEndpointBuilder.java:265)
at org.mule.endpoint.AbstractEndpointBuilder.doBuildOutboundEndpoint(AbstractEndpointBuilder.java:164)
at org.mule.endpoint.AbstractEndpointBuilder.buildOutboundEndpoint(AbstractEndpointBuilder.java:93)
at org.mule.endpoint.DefaultEndpointFactory.getOutboundEndpoint(DefaultEndpointFactory.java:86)
at org.mule.transport.cxf.transport.MuleUniversalConduit.initializeProtocolEndpoint(MuleUniversalConduit.java:302)
at org.mule.transport.cxf.transport.MuleUniversalConduit.getProtocolEndpoint(MuleUniversalConduit.java:276)
at org.mule.transport.cxf.transport.MuleUniversalConduit.dispatchMuleMessage(MuleUniversalConduit.java:230)
at org.mule.transport.cxf.transport.MuleUniversalConduit$1.handleMessage(MuleUniversalConduit.java:185)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220)
...

My customer needs this working asap so any help is very wellcome.

Thank you very much in advance.

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

http://xircles.codehaus.org/manage_email


Evangelina Moreno

unread,
Aug 31, 2011, 3:07:56 PM8/31/11
to us...@mule.codehaus.org
Hi Jose,

Which version of mule are you using?

There is nothing missing in the cxf:outbound-endpoint configuration, the exception you are getting is because mule is not being able to resolve the URI's prefix

wsdl-axis:https://${afirma.host}:${afirma.port}/afirmaws/services/ValidarFirma?wsdl

You can probably use an axis outbound-endpoint if you need to. Take a look at http://www.mulesoft.org/documentation/display/MULE2USER/Axis+Transport

As for the 'actor' attribute, mule is adding that value when there is an existing correlation ID and the ReplyTo header is also set, but if you set the enableMuleSoapHeaders to false, then it should be avoided anyhow (by default the value is true)

If you want to forward a WS call, you can configure mule to act as a proxy like this (this is just an example):

<service name="proxy">
<inbound>
<cxf:inbound-endpoint address="http://localhost:63081/services/proxy"
proxy="true"
synchronous="true"
enableMuleSoapHeaders="false"/>
</inbound>
<outbound>
<pass-through-router>
<cxf:outbound-endpoint address="http://localhost:63081/services/greeter"
proxy="true"
synchronous="true"
enableMuleSoapHeaders="false"/>

</pass-through-router>
</outbound>
</service>

Hope it helps,
Eva

Jose Ignacio

unread,
Sep 2, 2011, 4:24:46 AM9/2/11
to us...@mule.codehaus.org
Thank you Evangelina.


Mule deployment is: mule-standalone-2.2.1

I have made a first attempt with proxy="true", it fails because the spring bean (component) declared in the model does not implement org.mule.api.lifecycle.Callable. Will fix that and see what happens.


The problem really is that Mule is removing the whole SOAP header from the original message, that is only using its payload to build the outbound message. I need to maintain the original header intact, as it contains security data that the final endpoint requires (UsernameToken and such).


So, what is the best way (if any) to do that? Is it possible to tell Mule to forward the whole original message as is, with only the original headers?


Thank yo so much.

Jose

Evangelina Moreno

unread,
Sep 2, 2011, 1:26:17 PM9/2/11
to us...@mule.codehaus.org
Hi,

So if you want to forward the original message you should set the enableMuleSoapHeaders to false, that way you avoid any mule information being added there, and you would have to also set the payload to envelope to get the original headers you sent.

Eva

Jose Ignacio

unread,
Sep 5, 2011, 8:11:34 AM9/5/11
to us...@mule.codehaus.org
Hi,

Thanks for your response. It seems the payload attribute is not allowed in cxf:in/outbound-endpoint. Regardless, it fails with an exception. Attached is the config file and the mule log file. As you can see there, there is a Spring bean referenced in the service that implements the Callable interface. The callback (public Object onCall(MuleEventContext eventContext)) method in that bean is just returning null, I wonder if that may be the cause of the exception. Any ideas?


Thank you!


Jose

mule.log
afirma-config.xml

Evangelina Moreno

unread,
Sep 5, 2011, 10:26:59 AM9/5/11
to us...@mule.codehaus.org
Hi,

The payload attribute is allowed in the cxf endpoints, but it definitely seems that your problem is that the onCall method is returning null causing the NullPointerException to be thrown afterwards.

Jose Ignacio

unread,
Sep 5, 2011, 12:05:57 PM9/5/11
to us...@mule.codehaus.org
Hm, then there is something strange here. I get an exception if I add the payload attribute (attached).


The onCall method now returns "eventContext.getMessage()", but I have to wait untill tomorrow to test it.


Thank you Eva.

mule-parseException.log

Jose Ignacio

unread,
Sep 6, 2011, 3:55:41 AM9/6/11
to us...@mule.codehaus.org
The result is that the outbound message contains only the payload, without soap headers, and then the authentication fails at the final endpoint. I can't add payload="envelope" because it causes an error at mule startup. However in compile time it accepts the attribute, and the schema says its default value is "envelope".

In the attached log there is initially a +*Throwable*+ stacktrace internal to the cxf adapter. Might be a bug in the 2.2.1 version?


Thanks,

Jose

mule.log

Jose Ignacio

unread,
Sep 6, 2011, 6:35:11 AM9/6/11
to us...@mule.codehaus.org
Oh well, I have found this in the Mule CXF documentation: "Note that currently CXF proxies only support working with the SOAP body. They do not send the whole SOAP message along."

I could solve this issue if I could attach a SOAPHandler to the mule service. Can this be done?

Evangelina Moreno

unread,
Sep 6, 2011, 10:54:30 AM9/6/11
to us...@mule.codehaus.org
-- Oh well, I have found this in the Mule CXF documentation: "Note that currently CXF proxies only support working with the SOAP body. They do not send the whole SOAP message along."

This is an error in the documentation, the payload attribute was added to the proxy attributes to be able to specify that not just the body content should be forwarded. By default it just sends the body, but if you specify "envelope" as the payload, then the entire SOAP envelope should be send.
Mule 2.2.1 supports the attribute or you'd have a parsing exception initializing mule.

The documentation should be updated accordingly.

I will check a simple test case in mule's 2.2.1 distribution to discard a bug

-- I could solve this issue if I could attach a SOAPHandler to the mule service. Can this be done?

Mule allows you to add interceptors to the endpoints, check http://www.mulesoft.org/documentation/display/MULE2USER/CXF+Transport+Configuration+Reference in the Common CXF Endpoint Elements section.

Hope that helps,
Eva

Jose Ignacio

unread,
Sep 6, 2011, 12:08:50 PM9/6/11
to us...@mule.codehaus.org
"Mule 2.2.1 supports the attribute or you'd have a parsing exception initializing mule."

Yes, I have a parsing exception initializing Mule if I use the payload attribute. Please check the attached mule-parseException.log attached three posts above. But I hope this can be done because I am running out of ideas.


Cheers,

Jose

Jose Ignacio

unread,
Sep 8, 2011, 2:08:04 AM9/8/11
to us...@mule.codehaus.org
I have tried with Mule 3.1.2 and it works well with the attached configuration. I think our best option is to migrate the production server to the new version, or to have both versions running together while we migrate all the services/apps.
mule-config.xml
Reply all
Reply to author
Forward
0 new messages