Yes, I see it's only available in 2.4.2-SNAPSHOT and the trunk.
On Thu, Aug 4, 2011 at 4:40 PM, Jérôme Revillard <[email protected]> wrote: > Hi, > > It seems not to be in CXF 2.4.1. I will have to test the 2.5.0-SNAPSHOT > version. Anyway, to be clear, in fact it's the opposite, I do not want to > disable address updates but rather want it to be done for every request > (well, /services requests). Address overwriting was introduced for services page and WSDL be generated correctly, that was the only reason I believe. This is not needed for the services page be produced anymore, but may still be needed for WSDL generation - though I'm seeing that WSDLGetInterceptor uses REQUEST_URL and such, so may be it's actually not needed. If you can confirm that with 2.4.2-SNAPSHOT then IMHO using disableAddressUpdates will be exactly what you need - otherwise multiple threads will just interfere when overwriting the address Sergey > > Best, > Jerome > > > Le 04/08/2011 17:29, Sergey Beryozkin a écrit : >> >> 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 >>> ===================================================== >>> >>> >>> >> >> > > -- > ===================================================== > 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
