Hi Ingo, Yes, that sounds like a bug, however I can't reproduce it. This is what I did with the latest CXF 3.0.x branch code:
I built the STS war including in the CXF distribution including WS-MEX -> services/sts/sts-war: mvn clean install -Pcxf25 Copied the resulting war to a Tomcat 7 instance. I've added a unit test as part of this commit to download the WSDL via WS-MEX: https://git1-us-west.apache.org/repos/asf?p=cxf.git;a=commit;h=02c588ce So I just modified the port number to correspond to the port that Tomcat was running on, and looked at the output of the WSDL (printed in the console, if you turn on logging to INFO + enable the ConsoleHandler): <wsdl:port binding="wstrust:Transport_Binding" name="Transport_Port"> <soap:address location=" http://localhost:8080/SecurityTokenService/Transport"/> </wsdl:port> Could you try again with the latest CXF code to see if the problem persists? If it does, then maybe adapt this test-case with your WAR to see whether the returned address is correct or not? If it is incorrect, then please send me the updated war + I can try running it. Colm. On Tue, Jun 2, 2015 at 5:21 PM, Ingo <[email protected]> wrote: > 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. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
