Dear Colm, sorry for the delayed catchup, but in the meanwhile I found the time to debug the scenario and figured out the *root cause* *of the exception*, which I wanted to share, since it was NOT simple...
The setup of the cross_domain <https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain> systest was modified by myself in such way, that: * BSTS configuration was applied to the cxf sts-service <https://github.com/apache/cxf/blob/master/services/sts/sts-war> * BSTS got equipped with the WS-SecurityPolicy of the original cross_domain systest * Transport Security configuration (keystore, truststore, https port) was *handled by the servlet container* * BSTS war file is deployed in a servlet container (e.g. Tomcat or Jetty) There are differences in the jaxws:endpoint address property: /cross_domain systest/ --> address="https://localhost:30102/SecurityTokenService/b"; (see here <https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain/cxf-sts-saml2.xml#L64> ) compared to /sts service /sts-war/ --> address="/b" (in the style of this configuration <https://github.com/apache/cxf/blob/master/services/sts/sts-war/src/main/webapp/WEB-INF/cxf-transport.xml#L50> ) ...that strike through the *MEX response of BSTS* when running the test with BSTS deployed in Tomcat. Instead of having the correct, absolute service endpoint URL of the original test: only the relative address part is included in the MEX response:This leads to the initially mentioned exception during runtime configuration of the sts-client, since the comparison of the MEX response and the WS-SecurityPolicy (issuer address) of the service <https://github.com/apache/cxf/blob/master/services/sts/systests/advanced/src/test/resources/org/apache/cxf/systest/sts/cross_domain/DoubleIt.wsdl#L161> gives no match. Is there a way to "repair" the MEX response of the SecurityTokenService when having it deployed to a container? Should this be seen as a bug of the CXF WS-MEX implementation? best regards, Ingo -- View this message in context: http://cxf.547215.n5.nabble.com/Exception-when-trying-to-retrieve-process-a-WSDL-via-WS-MEX-tp5750835p5757894.html Sent from the cxf-user mailing list archive at Nabble.com.
