Re: schemaLocation URL rewriting

[Jérôme Revillard]

Hi all,






I think it would be good to modify:

            if (ad != null
&& (ad.equals(path))) {
                if (disableAddressUpdates) {

                                         base + path);
                } else {
                    BaseUrlHelper.setAddress(d2, base + path);
                }
            }

like this:

            if (disableAddressUpdates) {

                                     base + path);
            } else {
                BaseUrlHelper.setAddress(d2, base + path);
            }

What's your opinion? Is there a better way to solve my issue?

Best,
Jerome

Le 04/08/2011 14:10, Jérôme Revillard a écrit :

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. request.setAttribute("org.apache.cxf.transport.endpoint.address", request.setAttribute("org.apache.cxf.transport.endpoint.address",

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<jrevill...@maatg.fr> wrote:

Dear all,


responsive I first post here.
We use CXF inside tomcat to create web services. We use the wsdl first
method.

I don't know if it's a question for you or for tomcat but as you are very 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

I used the regular port forwarding stuff using iptables. But then, the
imports URLs are not well resolved:

For some reason, we must access the service using the default https port so 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?

that I look at the problem?

If this is resolved inside the CXF source code, could you tell me where so

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
=====================================================

smime.p7s
Description: Signature cryptographique S/MIME