You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2014/08/29 15:44:53 UTC

[jira] [Resolved] (CXF-5977) Calling a WebService in a different domain ends up in UnknownHostException because the domain is lost

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

Daniel Kulp resolved CXF-5977.
------------------------------

       Resolution: Not a Problem
    Fix Version/s: Invalid
         Assignee: Daniel Kulp


This is not a bug in CXF.  The WSDL that they have deployed is not completely valid.   If you point your browser at that WSDL url, you see:

{code}
<soap:address location="http://express03:18080/CARMEN-ejb/WebServiceController"/>
{code}

so they are not putting the full URL in the location like they should be.   

You can use the BindingProvider.ENDPOINT_ADDRESS_PROPERTY property on the context to override the soap:address location, but this should be reported to the service provider.

> Calling a WebService in a different domain ends up in UnknownHostException because the domain is lost
> -----------------------------------------------------------------------------------------------------
>
>                 Key: CXF-5977
>                 URL: https://issues.apache.org/jira/browse/CXF-5977
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7.12
>            Reporter: Björn Nebe
>            Assignee: Daniel Kulp
>             Fix For: Invalid
>
>         Attachments: Stacktrace.txt, codeexample.txt, part1.png, part2.png
>
>
> I have a client in one domain and a JBoss Application Server providing a WebService in a different domain. Calling the WebService ends up in a UnknownHostException, because during the read of the WSDL the domain part of the servername gets lost and the pure servername is not known. I debugged threw this and add the Stacktrace of the resulting exception and two screenshots showing in which member the wrong value can be found. If I change this member in memory by eclipse, the call works. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)