Hi On Thu, Aug 4, 2011 at 4:17 PM, Jérôme Revillard <[email protected]> wrote: > Hi all, > > Looking at this problem, I think that I found a bug inside CXF too. My use > case might be a bit specific because I can access the services for 2 > different ports in the same host: 8443 and 443. > > The problem is in the > org.apache.cxf.transport.servlet.ServletController#updateDests(HttpServletRequest > request, boolean force) method: BaseUrlHelper.setAddress is only called the > first time which is a problem for my use case. indeed, if the first request > is from the 8443 port for instance, the endpoint address will always be > resolved with the 8443 port in the next requests even if the used port is > then 443. > > I think it would be good to modify: > > if (ad != null > && (ad.equals(path))) { > if (disableAddressUpdates) { > > request.setAttribute("org.apache.cxf.transport.endpoint.address", > base + path); > } else { > BaseUrlHelper.setAddress(d2, base + path); > } > } > > like this: > > if (disableAddressUpdates) { > > request.setAttribute("org.apache.cxf.transport.endpoint.address", > base + path); > } else { > BaseUrlHelper.setAddress(d2, base + path); > } > > What's your opinion? Is there a better way to solve my issue? >
I think it's been fixed in CXF 2.4.1 - can you try it please ? One still needs to use disableAddressUpdates though for it to be thread-safe, otherwise BaseUriHelper.setAddress can be called concurrently... I think one more step is needed to completely disable the address overwriting, but for now please set a disableAddressUpdates in CXF 2.4.1 - this actually may also work in CXF 2.4.0/2.3.5 Cheers, Sergey > Best, > Jerome > > Le 04/08/2011 14:10, Jérôme Revillard a écrit : >> >> 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, Sergey >>> >>>> Jerome >>>> >>>> -- >>>> 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. >>>> >>> >>> >> > > -- > ===================================================== > Dr Jérôme Revillard > CTO MAAT France > www.maatg.com > > Immeuble Alliance Entree A, > 74160 Archamps (France) > > Mob. 0033 676 108 185 > Tel. 0033 450 439 602 > Fax. 0033 450 439 601 > ===================================================== > > > -- Sergey Beryozkin http://sberyozkin.blogspot.com Talend - http://www.talend.com
