JAX-RPC 和 Glassfish

Question

我有一个部署在 Weblogic 上的带有 JAX-RPC Web 服务的遗留应用程序。我正在尝试使用嵌入式 glassfish 围绕它创建一个测试工具，它是 ScatteredEAR。

该应用程序似乎部署良好，并且 Web 服务端点可用。但是，当我提出请求时，我会收到此异常。

SEVERE: ws.error_next_pipe
java.lang.ClassCastException: org.glassfish.webservices.monitoring.JAXRPCEndpointImpl cannot be cast to org.glassfish.webservices.monitoring.JAXWSEndpointImpl
at org.glassfish.webservices.MonitoringPipe.process(MonitoringPipe.java:123)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:136)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:210)
at com.sun.enterprise.security.webservices.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:142)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:1136)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:1050)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:1019)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:877)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:420)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:687)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:266)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:169)
at org.glassfish.webservices.JAXWSServlet.doPost(JAXWSServlet.java:169)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:744)

我不确定为什么将 JAXRPCEndpoint 强制转换为 JAXWSEndpoint。任何人都可以阐明可能发生的事情吗？

我还查看了 MonitoringPipe 的源代码，它只是将所有内容都转换为 JAXWSEndpoint。 Glassfish 是否不支持 JAXRPC？

另外，是否有机会禁用 MonitoringPipe？我尝试在 Glassfish 上禁用监控，但没有成功。

任何想法表示赞赏。

Answer 1

我不确定为什么将 JAXRPCEndpoint 强制转换为 JAXWSEndpoint。能 有人对可能发生的事情有所了解吗？

我猜这是因为MonitoringPipe 在这种情况下不希望任何JAXRPCEndpoint 作为端点。

我还查看了 MonitoringPipe 的来源，它只是强制转换 一切都到 JAXWSEndpoint。不支持 JAXRPC 的任何机会 玻璃鱼？

GlassFish v3 支持 JAX-RPC 1.1。来自 Oracle 文档：

支持基于 XML 的 Web 服务 (JAX-WS) 版本 2.2 的 Java API。 Java API for XML-Based Remote Procedure Calls (JAX-RPC) 1.1 版是 支持向后兼容。

docs 还包含更多详细信息。 GlassFish 4 应该同样有效。

另外，是否有机会禁用 MonitoringPipe？我试过了 禁用对 Glassfish 的监控，但没有运气。

您可以通过 server-config 的 Monitoring 部分中的管理 GUI 禁用对 GlassFish 不同部分的监控。我猜你已经试过了。

您还可以添加 JVM 属性 -Dcom.sun.xml.ws.monitoring.endpoint=false 看看是否有帮助。

任何想法表示赞赏。

来自问题JAX-WS vs. JAX-RPC：

JAX-RPC 是已在 Java EE 6（和 因此可能会从未来的版本中删除）。 修剪原因： JAX-RPC 是将 SOAP Web 服务建模为 RPC 调用的早期尝试。 Web 服务已经不再是 RPC 模型。这 更健壮、功能丰富和流行的有效 JAX-WS API 取代 JAX-RPC。

在没有看到任何代码的情况下，我只能猜测您使用了一种太旧的技术来实现您之前使用的 Weblogic 服务器支持的 web 服务，但您现在使用的 GlassFish 服务器不支持该技术。我猜您使用的是 v3 或更高版本，您可以尝试 GlassFish v2 上的 Web 应用程序。