Ok thanks for your help Sergey. Best, Jerome
Le 04/08/2011 17:56, Sergey Beryozkin a écrit :
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 SergeyBest, 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, SergeyBest, 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, 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
