cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Exception when trying to retrieve/process a WSDL via WS-MEX
Date Wed, 03 Jun 2015 11:13:34 GMT
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 <wolf.working@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message