You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by servicer-mixer <st...@yahoo.com> on 2008/10/19 08:02:24 UTC
CXF Proxy fault problem
I've set up a cxf proxy:
cxf-bc-consumer->cxf-bc-provider->external service
The external service requires ws-addressing and ws-security headers. So far
I've only set up the addressing headers and from logging can see that the
reply from the external service is a soap fault. However, when the client
receives the reply from the cxf-bc-consumer the message is missing the fault
and there is an empty body <soap:Body/>. I can also see the fault reply when
i make a request directly to the external service. The original wsdl for the
service was missing fault declarations for the operation/binding, but the
problem remains even after the fault declarations have been added:
...
<wsdl:operation name="Ping">
<wsdl:input message="tns:PingSoapIn"/>
<wsdl:output message="tns:PingSoapOut"/>
<wsdl:fault message="soap:fault" name="DefaultFault"/>
</wsdl:operation>
...
<wsdl:operation name="Ping">
<soap:operation soapAction="http://www.external.com/Ping"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="DefaultFault">
<soap:fault name="DefaultFault" use="literal" />
</wsdl:fault>
</wsdl:operation>
I'm not sure if this is similar to SM-1328, however, I've updated to 3.2.2
and still have the same problem.
Please let me know if there is something I'm missing.
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20053523.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Upon closer inspection I see the following in the logs:
WARNING: Failed to correlate message, aborting dispatch.
It looks like the replyTo id on the reply doesn't match the request message
id (addressing headers). I think this might be the issue...
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20079301.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Created: SM-1663
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20165090.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Append your configuration for the cxf bc endpoint should be fine.
Thanks
Freeman
servicer-mixer wrote:
> I created a Jira for the To header: SM-1661
> However, I'm not sure how to set up a test case for the https issue. The
> external service is a .Net application that appears to be running IIS6. The
> only error I can see is the http reply, the only difference I can see in the
> generated soap requests is that the Content-Type header is set to [text/xml,
> text/xml]. However, even if I remove the headers, I still get the same
> error.
>
> Thanks
>
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
You need delete the attachment first and re-upload it and select " Grant
license to ASF for inclusion in ASF works" radio button for the attachment.
servicer-mixer wrote:
> Sorry, haven't been on here for a few days. What's the procedure for granting
> license?
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Sorry, haven't been on here for a few days. What's the procedure for granting
license?
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20258724.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi Lars,
Yeah, it's a problem if you append attachment while you create the jira.
Currently if you want to grant apache license for the attachment, you
need append it to a jira which already exist.
Freeman
Lars Heinemann wrote:
> Freeman,
>
> the current situation in Jira is really odd. I created a issue for INFRA
> regarding the missing ASF permission stuff in the issue creation screen.
> (see INFRA-1768)
> This will probably prevent situations like this. :)
>
>
>
>
>
> Freeman Fang schrieb:
>
>> Hi,
>> The patch for SM-1661 is great, would you please grant your patch to
>> apache license so that I can apply it?
>> You may need delete it first and re-upload it and select " Grant
>> license to ASF for inclusion in ASF works" radio button.
>> Thanks
>> Freeman
>>
>> servicer-mixer wrote:
>>
>>> I created a Jira for the To header: SM-1661
>>> However, I'm not sure how to set up a test case for the https issue. The
>>> external service is a .Net application that appears to be running
>>> IIS6. The
>>> only error I can see is the http reply, the only difference I can see
>>> in the
>>> generated soap requests is that the Content-Type header is set to
>>> [text/xml,
>>> text/xml]. However, even if I remove the headers, I still get the same
>>> error.
>>>
>>> Thanks
>>>
>>>
>>
>
>
Re: CXF Proxy fault problem
Posted by Lars Heinemann <la...@compart.net>.
Freeman,
the current situation in Jira is really odd. I created a issue for INFRA
regarding the missing ASF permission stuff in the issue creation screen.
(see INFRA-1768)
This will probably prevent situations like this. :)
Freeman Fang schrieb:
> Hi,
> The patch for SM-1661 is great, would you please grant your patch to
> apache license so that I can apply it?
> You may need delete it first and re-upload it and select " Grant
> license to ASF for inclusion in ASF works" radio button.
> Thanks
> Freeman
>
> servicer-mixer wrote:
>> I created a Jira for the To header: SM-1661
>> However, I'm not sure how to set up a test case for the https issue. The
>> external service is a .Net application that appears to be running
>> IIS6. The
>> only error I can see is the http reply, the only difference I can see
>> in the
>> generated soap requests is that the Content-Type header is set to
>> [text/xml,
>> text/xml]. However, even if I remove the headers, I still get the same
>> error.
>>
>> Thanks
>>
>
>
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
The patch for SM-1661 is great, would you please grant your patch to
apache license so that I can apply it?
You may need delete it first and re-upload it and select " Grant license
to ASF for inclusion in ASF works" radio button.
Thanks
Freeman
servicer-mixer wrote:
> I created a Jira for the To header: SM-1661
> However, I'm not sure how to set up a test case for the https issue. The
> external service is a .Net application that appears to be running IIS6. The
> only error I can see is the http reply, the only difference I can see in the
> generated soap requests is that the Content-Type header is set to [text/xml,
> text/xml]. However, even if I remove the headers, I still get the same
> error.
>
> Thanks
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
I created a Jira for the To header: SM-1661
However, I'm not sure how to set up a test case for the https issue. The
external service is a .Net application that appears to be running IIS6. The
only error I can see is the http reply, the only difference I can see in the
generated soap requests is that the Content-Type header is set to [text/xml,
text/xml]. However, even if I remove the headers, I still get the same
error.
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20144207.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Would you please create jira tickets for both issues, and append your
testcase if possible?
Thanks
Freeman
servicer-mixer wrote:
> Updating to the 3.2.3-SNAPSHOT also causes the external service to return:
> Response was of unexpected text/html ContentType. Incoming portion of HTML
> stream: <h1>Bad Request (Invalid Header Name)</h1>
>
> for most of the messages i'm sending.
> Keeping all the configuration the same, the same exact requests succeeds in
> 3.2.2.
> I've tried removing all of the http headers before sending the message, but
> I still get the error.
>
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Updating to the 3.2.3-SNAPSHOT also causes the external service to return:
Response was of unexpected text/html ContentType. Incoming portion of HTML
stream: <h1>Bad Request (Invalid Header Name)</h1>
for most of the messages i'm sending.
Keeping all the configuration the same, the same exact requests succeeds in
3.2.2.
I've tried removing all of the http headers before sending the message, but
I still get the error.
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20135741.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Freeman Fang wrote:
>
> Hi,
>
> We needn't set the conduit into exchange explicitly.
> When you see the code in MAPAggregator
> ContextUtils.getConduit(conduit, message);
> It should run into AbstractConduitSelector.getSelectedConduit(), from
> which we get conduit from the EndpointInfo.
>
> Would you please try your tests with SMX 3.2.3 snapshot? I think the fix
> for SM-1593 should also fix this problem.
>
> Regards
> Freeman
>
>
Looks like the same thing happens with the 3.2.3 snapshot. Snapshot uses
2.0.9 version of cxf. Here is the ContextUtils.getConduit(conduit, message);
implementation:
public static Conduit getConduit(Conduit conduit, Message message) {
if (conduit == null) {
Exchange exchange = message.getExchange();
conduit = exchange != null ? exchange.getConduit(message) : null;
}
return conduit;
}
Exchange getConduit, does use the conduit selector, but that also seems
null.
Setting the conduit into the exchange in the CxfProvider still works. It
looks like the exchange wraps the conduit into a selector.
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20132896.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
We needn't set the conduit into exchange explicitly.
When you see the code in MAPAggregator
ContextUtils.getConduit(conduit, message);
It should run into AbstractConduitSelector.getSelectedConduit(), from
which we get conduit from the EndpointInfo.
Would you please try your tests with SMX 3.2.3 snapshot? I think the fix
for SM-1593 should also fix this problem.
Regards
Freeman
servicer-mixer wrote:
> It looks like the CxfProvider does not set the conduit into the exchange
> after creating it. It worked as expected after I modified the provider class
> to set the conduit into the exchange. Is this the correct fix or am I still
> missing something?
>
> Thanks
>
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
It looks like the CxfProvider does not set the conduit into the exchange
after creating it. It worked as expected after I modified the provider class
to set the conduit into the exchange. Is this the correct fix or am I still
missing something?
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20115892.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
I'm not 100% sure what the problem is...
I think the http conduit is being used, because external service is https
and I'm able to communicate with it.
However, when I step through the code the following code in
MAPAggregator.addRoleSpecific does not find a conduit in the exchange and
defaults To to the "none" address:
if (maps.getTo() == null) {
if (isOutbound) {
conduit = ContextUtils.getConduit(conduit, message);
}
EndpointReferenceType reference = conduit != null
? conduit.getTarget()
:
ContextUtils.getNoneEndpointReference();
maps.setTo(reference);
}
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20114773.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
You mean your target address in your https conduit can't be set in the
To address? Or you want the To address isn't the one in your conduit
configuration?
Freeman
servicer-mixer wrote:
> Freeman,
>
> I really appreciate your help with this. I've got it working now, but I
> still have one problem I had to hack my way through. Modifying the
> addressing name in an interceptor works fine, I have it added before the
> MAPCodec one. My interceptor retrieves the properties that are already there
> and then just changes the namespace. My only problem left is the To header.
> It looks like the MAPAggregator looks for a conduit and uses the target
> attribute. I have an https conduit configured. The only other examples I can
> find while googling is for jms, I'm not sure how to configure the the
> additional (addressing/soap/wsdl?) conduit with the target. However, I've
> been able to get it to work by setting the To header in my interceptor :).
> I'm pretty sure that's wrong though, is there any documentation available
> for configuring conduits?
>
> Thanks
>
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Freeman,
I really appreciate your help with this. I've got it working now, but I
still have one problem I had to hack my way through. Modifying the
addressing name in an interceptor works fine, I have it added before the
MAPCodec one. My interceptor retrieves the properties that are already there
and then just changes the namespace. My only problem left is the To header.
It looks like the MAPAggregator looks for a conduit and uses the target
attribute. I have an https conduit configured. The only other examples I can
find while googling is for jms, I'm not sure how to configure the the
additional (addressing/soap/wsdl?) conduit with the target. However, I've
been able to get it to work by setting the To header in my interceptor :).
I'm pretty sure that's wrong though, is there any documentation available
for configuring conduits?
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20095806.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
One workaround should work is that you can add an interceptor for your
cxf bc provider out interceptor chain, set the namespace to 2004/08
something like
AddressingBuilder builder = AddressingBuilder.getAddressingBuilder();
AddressingProperties maps = builder.newAddressingProperties();
((AddressingPropertiesImpl)maps).exposeAs("http://schemas.xmlsoap.org/ws/2004/08/addressing");
//associate MAPs with request context
Map<String, Object> requestContext = new Map<String, Object>();
requestContext.put(CLIENT_ADDRESSING_PROPERTIES, maps); then bind
this request context to your outgoing soap message
then bind the requestContext to your outgoing soapmessage, you should
ensure this interceptor get invoked before MAPAggregator and MAPCodec
Freeman
servicer-mixer wrote:
> Hi,
>
> I have the security and saaj configured on the outgoing messages. The
> security works fine. I think I have nailed the problem down to a mismatch in
> ws-addressing namespaces. The external service uses
> http://schemas.xmlsoap.org/ws/2004/08/addressing while cxf uses
> http://www.w3.org/2005/08/addressing.
>
> When I disable addressing interceptors, the headers are passed through to
> the external service and i get the expected reply on the consumer end.
>
> This is still not exactly what I'm looking for, but it should work for now.
>
> I've been trying to figure out how to change ws-addressing namespace used by
> cxf, but haven't had much luck... Something about ws-policy configuration
> with which I'm not yet familiar.
>
> Here is the provider cxf config as it is now:
>
> <bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
> <property name="inInterceptors">
> <list>
> <ref bean="loggingIn" />
> </list>
> </property>
> <property name="inFaultInterceptors">
> <list>
> <ref bean="loggingIn" />
> </list>
> </property>
> <property name="outInterceptors">
> <list>
> <bean
> class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor" />
> <ref bean="securityInterceptor" />
> <ref bean="loggingOut" />
> </list>
> </property>
> <property name="outFaultInterceptors">
> <list>
> <ref bean="loggingOut" />
> </list>
> </property>
> </bean>
>
> Thanks
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Hi,
I have the security and saaj configured on the outgoing messages. The
security works fine. I think I have nailed the problem down to a mismatch in
ws-addressing namespaces. The external service uses
http://schemas.xmlsoap.org/ws/2004/08/addressing while cxf uses
http://www.w3.org/2005/08/addressing.
When I disable addressing interceptors, the headers are passed through to
the external service and i get the expected reply on the consumer end.
This is still not exactly what I'm looking for, but it should work for now.
I've been trying to figure out how to change ws-addressing namespace used by
cxf, but haven't had much luck... Something about ws-policy configuration
with which I'm not yet familiar.
Here is the provider cxf config as it is now:
<bean id="cxf" class="org.apache.cxf.bus.CXFBusImpl">
<property name="inInterceptors">
<list>
<ref bean="loggingIn" />
</list>
</property>
<property name="inFaultInterceptors">
<list>
<ref bean="loggingIn" />
</list>
</property>
<property name="outInterceptors">
<list>
<bean
class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor" />
<ref bean="securityInterceptor" />
<ref bean="loggingOut" />
</list>
</property>
<property name="outFaultInterceptors">
<list>
<ref bean="loggingOut" />
</list>
</property>
</bean>
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20082355.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Would you please append the configuration file both for your cxf bc
provider and consumer? I think you also need security interceptors for
the incoming message of the provider.
Regards
Freeman
servicer-mixer wrote:
> Hi again.
> I really appreciate your help. I've updated the configuration to send
> security information to the service now.
> However, I'm still missing the body of the reply when returning from the
> consumer endpoint.
> I see the following:
>
> Logging from provider shows response as:
> <?xml version="1.0" encoding="utf-8"?>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
> <soap:Header>
> <wsa:Action>http://www.something.net/API/PingResponse</wsa:Action>
>
> <wsa:MessageID>urn:uuid:51c83f3f-8b7e-47db-8643-4b72456154e0</wsa:MessageID>
>
> <wsa:RelatesTo>urn:uuid:aff18395-86cc-447f-a620-0aa3d9565d74</wsa:RelatesTo>
>
> <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
> <wsse:Security>
> <wsu:Timestamp
> wsu:Id="Timestamp-f6f5b475-b6f9-42ee-932c-2189bc276182">
> <wsu:Created>2008-10-20T15:32:27Z</wsu:Created>
> <wsu:Expires>2008-10-20T15:37:27Z</wsu:Expires>
> </wsu:Timestamp>
> </wsse:Security>
> </soap:Header>
> <soap:Body>
> <PingResponse xmlns="http://www.something.net/API/">
> <PingResult>true</PingResult>
> </PingResponse>
> </soap:Body>
> </soap:Envelope>
>
> Final result received from consumer:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <MessageID
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:f535edd9-3efe-4bd7-ba0d-8afc28615057</MessageID>
> <RelatesTo
> xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:82AD6344EF708FFD431224262629989</RelatesTo>
> <Action
> xmlns="http://www.w3.org/2005/08/addressing">http://www.docusign.net/API/3.0/Ping</Action>
> </soap:Header>
> <soap:Body />
> </soap:Envelope>
>
> I have logging interceptors configured, but I don't see any exceptions.
> I have security interceptor configured on the out for the provider. I'm
> using 2 different bus config files one for consumer and another for provider
> (i'm configuring the interceptors on the bus, haven't been able to figure
> out how to use the jaxws:client or jaxws:endpoint...)
> Could there be something else I'm missing?
>
> Thanks
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Hi again.
I really appreciate your help. I've updated the configuration to send
security information to the service now.
However, I'm still missing the body of the reply when returning from the
consumer endpoint.
I see the following:
Logging from provider shows response as:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<soap:Header>
<wsa:Action>http://www.something.net/API/PingResponse</wsa:Action>
<wsa:MessageID>urn:uuid:51c83f3f-8b7e-47db-8643-4b72456154e0</wsa:MessageID>
<wsa:RelatesTo>urn:uuid:aff18395-86cc-447f-a620-0aa3d9565d74</wsa:RelatesTo>
<wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsse:Security>
<wsu:Timestamp
wsu:Id="Timestamp-f6f5b475-b6f9-42ee-932c-2189bc276182">
<wsu:Created>2008-10-20T15:32:27Z</wsu:Created>
<wsu:Expires>2008-10-20T15:37:27Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soap:Header>
<soap:Body>
<PingResponse xmlns="http://www.something.net/API/">
<PingResult>true</PingResult>
</PingResponse>
</soap:Body>
</soap:Envelope>
Final result received from consumer:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<MessageID
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:f535edd9-3efe-4bd7-ba0d-8afc28615057</MessageID>
<RelatesTo
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:82AD6344EF708FFD431224262629989</RelatesTo>
<Action
xmlns="http://www.w3.org/2005/08/addressing">http://www.docusign.net/API/3.0/Ping</Action>
</soap:Header>
<soap:Body />
</soap:Envelope>
I have logging interceptors configured, but I don't see any exceptions.
I have security interceptor configured on the out for the provider. I'm
using 2 different bus config files one for consumer and another for provider
(i'm configuring the interceptors on the bus, haven't been able to figure
out how to use the jaxws:client or jaxws:endpoint...)
Could there be something else I'm missing?
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20072669.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
servicer-mixer wrote:
> Thank you for the quick responses. I'm not sure what the release schedule for
> 3.2.3 is. Is there a way to configure cxf consumer->producer as a pure proxy
>
Servicemix 3.2.3 should be released in one/two weeks.
> for now? I'm just looking to get the entire soap envelope passed through to
> the external service and then get an unaltered reply back.
>
I'm not sure what you mean for "pure proxy", so far we have problem of
SM-1637(which already addressed in 3.2.3 snapshot), which means the
reply fault message from external webservice without fault details (it's
runtime exception generally or exception thrown when process the soap
headers, your exception is the latter case) can't be send back through
cxfbc provider====>consumer, but other soap messages (normal
request/response or soap fault message caused by predefined exception so
that has details here) can go back and forth.
> Thanks
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Thank you for the quick responses. I'm not sure what the release schedule for
3.2.3 is. Is there a way to configure cxf consumer->producer as a pure proxy
for now? I'm just looking to get the entire soap envelope passed through to
the external service and then get an unaltered reply back.
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20061177.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
There is a bug for cxf bc provider process the soap fault message which
only have faultstring but no fault detail, there is already an issue[1]
to track it, and I will fix it asap
[1]https://issues.apache.org/activemq/browse/SM-1637
Freeman
servicer-mixer wrote:
> Here it goes:
>
> <?xml version="1.0" encoding="utf-8"?>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
> <soap:Header>
> <wsa:Action>
> http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
> </wsa:Action>
> <wsa:MessageID>urn:uuid:a00aaa1c-f938-43d0-badf-0fd97aba6f36
> </wsa:MessageID>
> <wsa:RelatesTo>urn:uuid:c468ded3-3fd2-4d78-88c2-29f107fd7a8c
> </wsa:RelatesTo>
> <wsa:To>
> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
> </wsa:To>
> <wsse:Security>
> <wsu:Timestamp
> wsu:Id="Timestamp-064f39d0-e3aa-4fa1-8de7-9ca067321a91">
> <wsu:Created>2008-10-19T13:22:29Z
> </wsu:Created>
> <wsu:Expires>2008-10-19T13:27:29Z
> </wsu:Expires>
> </wsu:Timestamp>
> </wsse:Security>
> </soap:Header>
> <soap:Body>
> <soap:Fault>
> <faultcode
>
> xmlns:q0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">q0:Security</faultcode>
> <faultstring>Security requirements are not satisfied
> because the security header is not present in the incoming
> message.</faultstring>
> <faultactor>https://someactor.com/api/
> </faultactor>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
>
> Thanks
>
>
Re: CXF Proxy fault problem
Posted by servicer-mixer <st...@yahoo.com>.
Here it goes:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<soap:Header>
<wsa:Action>
http://schemas.xmlsoap.org/ws/2004/08/addressing/fault
</wsa:Action>
<wsa:MessageID>urn:uuid:a00aaa1c-f938-43d0-badf-0fd97aba6f36
</wsa:MessageID>
<wsa:RelatesTo>urn:uuid:c468ded3-3fd2-4d78-88c2-29f107fd7a8c
</wsa:RelatesTo>
<wsa:To>
http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
</wsa:To>
<wsse:Security>
<wsu:Timestamp
wsu:Id="Timestamp-064f39d0-e3aa-4fa1-8de7-9ca067321a91">
<wsu:Created>2008-10-19T13:22:29Z
</wsu:Created>
<wsu:Expires>2008-10-19T13:27:29Z
</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soap:Header>
<soap:Body>
<soap:Fault>
<faultcode
xmlns:q0="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">q0:Security</faultcode>
<faultstring>Security requirements are not satisfied
because the security header is not present in the incoming
message.</faultstring>
<faultactor>https://someactor.com/api/
</faultactor>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Thanks
--
View this message in context: http://www.nabble.com/CXF-Proxy-fault-problem-tp20053523p20056084.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: CXF Proxy fault problem
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Could you dump the soap fault message back from your external service?
Freeman
servicer-mixer wrote:
> I've set up a cxf proxy:
> cxf-bc-consumer->cxf-bc-provider->external service
>
> The external service requires ws-addressing and ws-security headers. So far
> I've only set up the addressing headers and from logging can see that the
> reply from the external service is a soap fault. However, when the client
> receives the reply from the cxf-bc-consumer the message is missing the fault
> and there is an empty body <soap:Body/>. I can also see the fault reply when
> i make a request directly to the external service. The original wsdl for the
> service was missing fault declarations for the operation/binding, but the
> problem remains even after the fault declarations have been added:
>
> ...
> <wsdl:operation name="Ping">
> <wsdl:input message="tns:PingSoapIn"/>
> <wsdl:output message="tns:PingSoapOut"/>
> <wsdl:fault message="soap:fault" name="DefaultFault"/>
> </wsdl:operation>
> ...
> <wsdl:operation name="Ping">
> <soap:operation soapAction="http://www.external.com/Ping"
> style="document"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> <wsdl:fault name="DefaultFault">
> <soap:fault name="DefaultFault" use="literal" />
> </wsdl:fault>
> </wsdl:operation>
>
> I'm not sure if this is similar to SM-1328, however, I've updated to 3.2.2
> and still have the same problem.
>
> Please let me know if there is something I'm missing.
>
> Thanks
>