Веб-сервис недоступен после перезапуска Glassfish

Question

сейчас у меня есть эта новая проблема. Я использую Glassfish 3.1.2.2 для размещения приложения, которое имеет веб-службу для связи с другим приложением вне сервера, в основном с настольным приложением swing. Все отлично работает, но (всегда но, но), если нам по какой-то причине нужно перезапустить стеклянную рыбку, приложение для удаления не нашло ws, поэтому нам нужно перераспределить приложение в Glassfish, и все будет хорошо работать.

В начале мы думали, что это проблема в настольном клиенте, поэтому мы обновляем соединение с веб-службой, ничего. После этого, мы протестировали веб-сервис от варианта Netbeans, чтобы сделать это, и мы получаем следующее предупреждение:

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

Мое приложение построено с помощью jdk 7.0.21, используя Netbeans 7.3, JSF 2.0, PrimeFaces 3.5, JPA 2.0, веб-сервис был создан после этого tutorial.

Это сообщение получено в журнале тестового настольного приложения:

Исключение в потоке «АВТ-EventQueue-0» com.sun.xml.internal.ws.client.ClientTransportException: Сервер отправленный код статуса HTTP 404: не найден на com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode (HttpTransportPipe.java:296) на com.sun.xml.internal.ws.transport. http.client.HttpTransportPipe.createResponsePacket (HttpTransportPipe.java:245) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process (HttpTransportPipe.java:203) at com.sun.xml. между nal.ws.transport.http.client.HttpTransportPipe.processRequest (HttpTransportPipe.java:122) at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest (DeferredTransportPipe.java:95) at com.sun. xml.internal.ws.api.pipe.Fiber .__ doRun (Fiber.java:626) at com.sun.xml.internal.ws.api.pipe.Fiber._doRun (Fiber.java:585) at com. sun.xml.internal.ws.api.pipe.Fiber.doRun (Fiber.java:570) at com.sun.xml.internal.ws.api.pipe.Fiber.runSync (Fiber.java:467) at com.sun.xml.internal.ws.client.Stub.process (Stub.java:308) at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess (SEIStub.java:146) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke (SyncMethodHandler.java:98) at com.sun.xml.intern al.ws.client.sei.SyncMethodHandler.invoke (SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke (SEIStub.java:129) at com.sun. прокси. $ Proxy30.hello (Unknown Source) на com.spontecorp.testws.TestWSFrame.invokeWSButtonActionPerformed (TestWSFrame.java:137) в com.spontecorp.testws.TestWSFrame.access $ 100 (TestWSFrame.java:14) на ком .spontecorp.testws.TestWSFrame $ 2.actionPerformed (TestWSFrame.java:62) at javax.swing.AbstractButton.fireActionPerformed (AbstractButton.java:2018) at javax.swing.AbstractButton $ Handler.actionPerformed (AbstractButton.java:2341) at javax.swing.DefaultButtonModel.fireActionPerformed (DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPress ред (DefaultButtonModel.java:259) на javax.swing.plaf.basic.BasicButtonListener.mouseReleased (BasicButtonListener.java:252) на java.awt.Component.processMouseEvent (Component.java:6505) в javax.swing. JComponent.processMouseEvent (JComponent.java: 3321) at java.awt.Component.processEvent (Component.java:6270) at java.awt.Container.processEvent (Container.java:2229) at java.awt.Component.dispatchEventImpl (Component.java: 4861) на java.awt.Container.dispatchEventImpl (Container.java:2287) в java.awt.Component.dispatchEvent (Component.java:4687) в java.awt.LightweightDispatcher.retargetMouseEvent (Container.java:4832) на java.awt.LightweightDispatcher.processMouseEvent (Container.java:4492) в java.awt.LightweightDispatcher.dispatchEvent (Container.java:4422) в java.awt.Container.dispatchEventImpl (Container.java:2273) на java.awt.Window.dispatchEventImpl (Window.java:2719) at java.awt.Component.dispatchEvent (Component.java:4687) at java.awt.EventQueue.dispatchEventImpl (EventQueue.java:729) at java.awt.EventQueue.access $ 200 (EventQueue.java:103) в java .awt.EventQueue $ 3.run (EventQueue.java:688) at java.awt.EventQueue $ 3.run (EventQueue.java:686) at java.security.AccessController.doPrivileged (собственный метод) at java.security. ProtectionDomain $ 1.doIntersectionPrivilege (ProtectionDomain.java:76) в java.security.ProtectionDomain $ 1.doIntersectionPrivilege (ProtectionDomain.java:87) в java.awt.EventQueue $ 4.run (EventQueue.java:702) в java.awt .EventQueue $ 4.run (EventQueue.java:700) в java.security.AccessController.doPrivileged (собственный метод) в java.security.ProtectionDomain $ 1.doIntersectionPrivilege (ProtectionDomain.java:76) в java.awt.EventQueue.dispatchEvent (EventQueue.java:699) в java.awt.EventDispatchThread.pumpOneEventForFilters (EventDispatchThread.java:242) на java.awt.EventDispatchThread.pumpEventsForFilter (EventDispatchThread.java:161) в java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:150) в java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:146) на Java .awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:138) на java.awt.EventDispatchThread.run (EventDispatchThread.java:91)

Мой вопрос: - Нужно ли мне что-то настраивать в Glassfish после развертывания приложения, которое обслуживает веб-сервис ?, если да, то где?

Answer 1

При такой же проблеме после рефракционирования пришлось создать новый веб-сервис на сервере (а затем просто скопировать старый код), после чего я снова импортировал новый WSDL и внесли правильные изменения в код (к новому имя веб-службы).

Проблема была, для меня, по крайней мере, после того, как refractoring я не мог назвать

com.package.class.MyWebService_Service service; 

не знает, почему, и есть, вероятно, лучшее решение для этого вместо «воссоздания».

Answer 2

Я не знаю, поможет ли это вам в вашем случае, но, по крайней мере, tutorial не работал ни для меня, ни из-под коробки. Ошибка, которую я получил, была такой же: «com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 404: Not Found».

Мне удалось заставить клиента веб-службы работать, повторно создавая ссылку на веб-службу. Проблема заключалась в том, что он ссылался на http://localhost:8080/FlowerAlbumService/FlowerService?wsdl, но служба работала на http://localhost:8080/FlowerServiceService/FlowerService?wsdl (вы можете видеть это на testing the web service).

Таким образом, я удалил веб-службу на узле ссылок веб-службы клиента, создал новый клиент веб-службы и указал http://localhost:8080/FlowerServiceService/FlowerService?wsdl в качестве URL-адреса WSDL. Возможно, это также помогает решить вашу проблему.