[ 
https://issues.apache.org/jira/browse/CXF-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wojtek Malinowski closed CXF-4513.
----------------------------------

    
> First request to a webservice overrides jaxws:endpoint address parameter.
> -------------------------------------------------------------------------
>
>                 Key: CXF-4513
>                 URL: https://issues.apache.org/jira/browse/CXF-4513
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.6.2
>         Environment: windows xp/linux debian, tomcat 6.0.29/6.0.35, java 
> 1.6.22
>            Reporter: Wojtek Malinowski
>
> I have prepared some webservice, which has an endpoint configured as follows:
> <jaxws:endpoint id="authorization" 
> implementor="test.AuthorizationWebServiceImpl" 
> wsdlLocation="WEB-INF/wsdl/authorization.wsdl" 
> address="/AuthorizationWebService">
> Having deployed my webservice using CXF 2.6.2 to the tomcat server (6.0.29) 
> locally (but the same situation is on production systems), I'm going into 
> http://localhost:8080/MyService/services servlet and there I'm getting such 
> info:
> {code}
> publishedEndpointUrl: null
> address: /AuthorizationWebService
> Endpoint address: 
> http://localhost:8080/MyService/services/AuthorizationWebService
> WSDL : {http://test/authorization}AuthorizationService
> Target namespace: http://test/authorization
> {code}
> This is non-standard, because I modified FormattedServiceListWrite to have 
> publishedEndpointUrl and address on the screen:
> {code}
>         writer.write("<span class=\"field\">publishedEndpointUrl:</span> " + 
> "<span class=\"value\">"
>                      + 
> sd.getEndpointInfo().getProperty("publishedEndpointUrl") + "</span>");
>         writer.write("<br/><span class=\"field\">address:</span> " + "<span 
> class=\"value\">"
>                      + sd.getEndpointInfo().getAddress() + "</span>");
> {code}
> This is a correct situation, the endpoint address is taken from my request.
> But after I called some function from this webservice (and a requested path 
> contains localhost), the returned info changes to:
> {code}
> publishedEndpointUrl: null
> address: http://localhost:8080/MyService/services/AuthorizationWebService
> Endpoint address: 
> http://localhost:8080/MyService/services/AuthorizationWebService
> WSDL : {http://test/authorization}AuthorizationService
> Target namespace: http://test/authorization
> {code}
> This is worse, because when I try to call this servlet using 
> http://127.0.0.1:8080/MyService/services I will still get the reference with 
> localhost:8080. The next request to this webservice (calling another 
> function) using address 127.0.0.1 does not change the address. But if I 
> called my function for the first after restarting the tomcat using 127.0.0.1 
> then it would like this:
> {code}
> publishedEndpointUrl: null
> address: http://127.0.0.1:8080/MyService/services/AuthorizationWebService
> Endpoint address: 
> http://127.0.0.1:8080/MyService/services/AuthorizationWebService
> WSDL : {http://test/authorization}AuthorizationService
> Target namespace: http://test/authorization
> {code}
> To sum up, the address parameter is changed from /AuthorizationWebService to 
> REQUEST_PATH/AuthorizationWebService during the first request to the 
> webservice. This results in incorrect paths showed by the cxf servlet, when 
> webservice is available (and requested by users) through more than one 
> address.
> I think the correct behaviour would be that the address parameter would never 
> change, so when I request the servlet listing webservice the "basePath" 
> parameter would still be used to determine the full path despite user 
> requests in a meantime (and would be the same for all webservice as it is 
> before the first request).
> Tested on CXF 2.6.2 using windows xp or linux debian, java 1.6.22 and tomcat 
> 6.0.29 (linux) or 6.0.35 (windows).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to