Hi, Indeed, I just checked and it sounds to be a Tomcat issue as you said... I will investigate further.
Thanks, Jérôme Le 04/08/2011 10:01, Sergey Beryozkin a écrit :
Hi On Thu, Aug 4, 2011 at 7:10 AM, Jerome Revillard<[email protected]> wrote:Dear all, I don't know if it's a question for you or for tomcat but as you are very responsive I first post here. We use CXF inside tomcat to create web services. We use the wsdl first method. In some of our WSDL, we import xsd files. WHen we create the wsdl, the paths are relative to the wsdl path (i.e: schemaLocation="./xsd/job.xsd"). When we deploy it and if we use the default tomcat https port everything if fine: https://sec-gw-ng-devel2.maatg.fr:8443/pandora-gateway-sal-saga/job?wsdl For some reason, we must access the service using the default https port so I used the regular port forwarding stuff using iptables. But then, the imports URLs are not well resolved: https://sec-gw-ng-devel2.maatg.fr/pandora-gateway-sal-saga/job?wsdl. As you can see, it's written "https://sec-gw-ng-devel2.maatg.fr:80"; ... Could you tell me if it's a CXF issue or not? If this is resolved inside the CXF source code, could you tell me where so that I look at the problem?CXF uses what the underlying container reports, have a look at ServletController.updateDestination, AbstractHTTPDestination.setupMessage, WSDLGetInterceptor. I suspect it's a sifeeffect of using iptables, but I'm not sure :-), possibly an issue in Tomcat too.., Cheers, SergeyJerome -- View this message in context: http://cxf.547215.n5.nabble.com/schemaLocation-URL-rewriting-tp4665281p4665281.html Sent from the cxf-user mailing list archive at Nabble.com.
smime.p7s
Description: Signature cryptographique S/MIME
