Результат wsimport имеет другую конечную точку выполнения.

Question

Это странный вариант.

Я генерация коды клиента для службы мыла с использованием wsimport плагин для Maven, как это ...

 <plugin> 
      <groupId>org.jvnet.jax-ws-commons</groupId> 
      <artifactId>jaxws-maven-plugin</artifactId> 
      <version>2.1</version> 
      <executions> 
      <execution> 
       <goals> 
       <goal>wsimport</goal> 
       </goals> 
       <configuration> 
       <wsdlUrls> 
        <wsdlUrl>${testWsdlLocationUrl}</wsdlUrl> 
       </wsdlUrls> 
       <destDir>${basedir}/target/jaxws</destDir> 
       </configuration> 
      </execution> 
      </executions> 
     </plugin> 

... где я параметризируюсь внешний wsdlUrl. Я могу видеть, где адрес URL WSDL (состряпал для анонимности) определяется в сгенерированной клиента, как это ...

static { 
    URL url = null; 

    try { 
     URL e = SpecialService.class.getResource("."); 
     url = new URL(e, "http://theUrlThatIDefinedAbove:withTheCorrectPortNumber/blahblah?wsdl"); 
    } catch (MalformedURLException var2) { 
     logger.warning("Failed to create URL for the wsdl Location: \'http://theUrlThatIDefinedAbove:withTheCorrectPortNumber/blahblah?wsdl\', retrying as a local file"); 
     logger.warning(var2.getMessage()); 
    } 

    SPECIALSERVICE_WSDL_LOCATION = url; 
} 

... так что все выглядит хорошо до сих пор. Сборка создает банку, содержащую только скомпилированный код, созданный из wsimport.

Однако, когда я обращаюсь к этому сгенерированному клиенту в своем коде для вызова службы, конечная точка отличается! Вот (суть), что я делаю ...

this.serviceEndpoint = new SpecialService().getSpecialServiceHttpSoap11Endpoint(); 

this.serviceEndpoint.callTheSpecialMethodOnTheService (withSomeDataOrOther)

достаточно просто да? Однако я получаю исключение тайм-аута.

Когда я смотрю на услуги конечной точки, как это:

System.out.println("Service Endpoint : " + this.serviceEndpoint.toString()); 

я (что-то вроде) ...

Service Endpoint : JAX-WS RI 2.2.4-b01: Stub for http://theCorrectUrlHere:8080/withTheCorrectPath/ 

... откуда 8080 пришел? Это не указано в URL-адресе wsdl.

Интересно, если я вручную изменить конечную точку службы, как это ... ((BindingProvider) this.serviceEndpoint) .getRequestContext(). Положим (BindingProvider.ENDPOINT_ADDRESS_PROPERTY "theCorrectUrlAndPort")

... все работает и я могу с радостью получить доступ к удаленной службе.

Я пропустил что-то очевидное? Я предположил, что предоставление wsimport местоположения wsdl будет испечь правильную конечную точку в клиентском коде, и это, безусловно, выглядит так, что данные хоста и пути корректны, но порт ошибочен.

Возможно, я сделал что-то глупое с помощью плагина wsimport? Нужно ли мне поставлять порт в wsimport?

Я был бы признателен за любые предложения, которые вы можете предоставить.

EDIT

По предложению Лео, вот новый плагин конфигурации ...

<testWsdlLocationUrl>http://editedOutHost:portThatIsNot8080/the/rest/of/the/path?wsdl</testWsdlLocationUrl> 

...

 <plugin> 
      <groupId>org.codehaus.mojo</groupId> 
      <artifactId>jaxws-maven-plugin</artifactId> 
      <executions> 
       <execution> 
        <id>generate-stubs</id> 
        <phase>process-classes</phase> 
        <goals> 
         <goal>wsimport</goal> 
        </goals> 
        <configuration> 
         <wsdlUrls> 
          <wsdlUrl>${testWsdlLocationUrl}</wsdlUrl> 
         </wsdlUrls> 
         <wsdlLocation>${testWsdlLocationUrl}</wsdlLocation> 
        </configuration> 
       </execution> 
      </executions> 
     </plugin> 

Пожалуйста, обратите внимание, что указывает на место удаленного WSDL, а не локальный в вашем комментарии.

Изменение плагина генерирует классы таким же образом, как и в моем первоначальном вопросе, при декомпиляции оба указывают на правильный хост-порт и путь, и оба они по-прежнему имеют одинаковую проблему с портированием порта до 8080.

* ОБНОВЛЕНО *

Та же проблема возникает, когда я вручную запустить wsimport из командной строки и баночки образовавшихся классов, так что я не думаю, что использование мавенно является источником проблемы.

Answer 1

Да, я отвечая на мой собственный вопрос. Я делаю это в интересах любого из переживших эту проблему в будущем.

Я только что услышал от ребята, у которого есть служба, с которой я пытался связаться, с таинственно меняющимся портом.

Их сервер «...» работает в нашей внутренней сети на портах 8080 и 8443 и создается извне, используя NAT с трансляциями портов. Таким образом, порты, показанные в файлах WSDL, являются теми (un), которые известны сервер «.

Итак, у нас оно есть. Порты, доступные для захвата wsdls, могут быть недоступны для вызовов службы. Разве это не странно?

Answer 2

Попробуйте использовать Codehaus плагин, будет полезно для сортировки проблем, связанных с WSDL местоположение

<plugin> 
     <groupId>org.codehaus.mojo</groupId> 
     <artifactId>jaxws-maven-plugin</artifactId> 
     <executions> 
      <execution> 
       <id>generate-wsdl</id> 
       <phase>process-classes</phase> 
       <goals> 
        <goal>wsgen</goal> 
       </goals> 
       <configuration> 
        <sei><!-- fully qualified class name goes here --></sei> 
        <genWsdl>true</genWsdl> 
       </configuration> 
      </execution> 
      <execution> 
       <id>generate-stubs</id> 
       <phase>process-classes</phase> 
       <goals> 
        <goal>wsimport</goal> 
       </goals> 
       <configuration> 
        <wsdlDirectory>target/jaxws/wsgen/wsdl</wsdlDirectory> 
        <wsdlFiles>     
         <wsdlFile><!-- class name goes here -->Service.wsdl</wsdlFile> 
        </wsdlFiles> 
        <!-- *** you need the next line to set the wsdlLocation in the generated stubs *** --> 
        <wsdlLocation>http://localhost:8080/test</wsdlLocation> 
       </configuration> 
      </execution> 
     </executions> 
    </plugin>