Wildfly 中的 JAX-WS Metro 实现
JAX-WS Metro implementation in Wildfly
我曾尝试使用 Wildfly 10 中的 JAX-WS Metro
实现更改默认 (CXF
) 实现。我必须执行大量步骤(遵循此 link)并适应野蝇 10.
- 禁用网络服务子系统。
- 添加 Metro 实现 jar 作为模块
- 提供了 javax.xml.ws.spi.Provider 文件。
- 从 javax 模块中禁用 org.jboss.modules。
但是服务器启动时,初始化出现异常。这是堆栈跟踪。看起来仍在实例化 jboss __XMLInputFactory
而不是 Metro
一个。
有什么想法吗?我试图添加一个文件 services/javax.xml.stream.XMLInputFactory 低于 class 但没有成功。
com.sun.xml.internal.stream.XMLInputFactoryImpl
堆栈跟踪
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.run(UndertowDeploymentService.java:85)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.RuntimeException: javax.servlet.ServletException: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.run(UndertowDeploymentService.java:82)
... 6 more
Caused by: javax.servlet.ServletException: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:66)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:184)
... 8 more
Caused by: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:137)
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:61)
... 9 more
Caused by: java.lang.ExceptionInInitializerError
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:144)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:127)
... 10 more
Caused by: java.lang.ClassCastException: __redirected.__XMLInputFactory cannot be cast to javax.xml.stream.XMLInputFactory
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.getXMLInputFactory(XMLStreamReaderFactory.java:109)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.<clinit>(XMLStreamReaderFactory.java:78)
... 12 more
我发现这是由于 classloader
问题导致 XMLInputFactoryImpl
被加载到多个类加载器中。我的问题中提到的步骤在 wildfly
版本中不起作用,因为它的行为与其前身不同。
我已经设法找到自己的方法使 Metro
在 wildfly 10
中工作,如下所示。
- packaged the metro implementation in the ear itself. And no other module hack needed. (refer pom.xml)
- removed the default webservice module (refer jboss-deployment-structure.xml)
- Added JNDI lookup for each EJBs to refer them inside WAR. It looks like CDI injection
@EJB
does not work due to this procedure, hence
will have to use JNDI.
jboss-部署-structure.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<!-- This means that the sub deployments of the EAR will have automatic
dependencies on each other except for WAR sub deployments. -->
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<exclude-subsystems>
<subsystem name="webservices" />
<subsystem name="jaxrs" />
</exclude-subsystems>
<!-- needed for SOAPHandler otherwise not required. -->
<dependencies>
<module name="com.sun.xml.messaging.saaj" export="true" services="export" />
</dependencies>
</deployment>
</jboss-deployment-structure>
pom.xml
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>webservices-rt</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-api</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>com.sun.tools.ws</groupId>
<artifactId>webservices-tools</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-extra-api</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>webservices-extra</artifactId>
<version>2.1-b16</version>
</dependency>
JNDI 查找
// get the deployed name from startup log for each EJBs deployed
deployedName = "java:global/example-ear-2.0-SNAPSHOT/logic/ExampleBean!org.example.com.ExampleBean";
T ejb = (T) initialContext.lookup(deployedName);
我曾尝试使用 Wildfly 10 中的 JAX-WS Metro
实现更改默认 (CXF
) 实现。我必须执行大量步骤(遵循此 link)并适应野蝇 10.
- 禁用网络服务子系统。
- 添加 Metro 实现 jar 作为模块
- 提供了 javax.xml.ws.spi.Provider 文件。
- 从 javax 模块中禁用 org.jboss.modules。
但是服务器启动时,初始化出现异常。这是堆栈跟踪。看起来仍在实例化 jboss __XMLInputFactory
而不是 Metro
一个。
有什么想法吗?我试图添加一个文件 services/javax.xml.stream.XMLInputFactory 低于 class 但没有成功。
com.sun.xml.internal.stream.XMLInputFactoryImpl
堆栈跟踪
com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.run(UndertowDeploymentService.java:85)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.RuntimeException: javax.servlet.ServletException: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.run(UndertowDeploymentService.java:82)
... 6 more
Caused by: javax.servlet.ServletException: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:66)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:184)
... 8 more
Caused by: com.sun.xml.ws.transport.http.servlet.WSServletException: WSSERVLET11: failed to parse runtime descriptor: java.lang.ExceptionInInitializerError
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:137)
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:61)
... 9 more
Caused by: java.lang.ExceptionInInitializerError
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:144)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:127)
... 10 more
Caused by: java.lang.ClassCastException: __redirected.__XMLInputFactory cannot be cast to javax.xml.stream.XMLInputFactory
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.getXMLInputFactory(XMLStreamReaderFactory.java:109)
at com.sun.xml.ws.api.streaming.XMLStreamReaderFactory.<clinit>(XMLStreamReaderFactory.java:78)
... 12 more
我发现这是由于 classloader
问题导致 XMLInputFactoryImpl
被加载到多个类加载器中。我的问题中提到的步骤在 wildfly
版本中不起作用,因为它的行为与其前身不同。
我已经设法找到自己的方法使 Metro
在 wildfly 10
中工作,如下所示。
- packaged the metro implementation in the ear itself. And no other module hack needed. (refer pom.xml)
- removed the default webservice module (refer jboss-deployment-structure.xml)
- Added JNDI lookup for each EJBs to refer them inside WAR. It looks like CDI injection
@EJB
does not work due to this procedure, hence will have to use JNDI.
jboss-部署-structure.xml
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<!-- This means that the sub deployments of the EAR will have automatic
dependencies on each other except for WAR sub deployments. -->
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<exclude-subsystems>
<subsystem name="webservices" />
<subsystem name="jaxrs" />
</exclude-subsystems>
<!-- needed for SOAPHandler otherwise not required. -->
<dependencies>
<module name="com.sun.xml.messaging.saaj" export="true" services="export" />
</dependencies>
</deployment>
</jboss-deployment-structure>
pom.xml
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>webservices-rt</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-api</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>com.sun.tools.ws</groupId>
<artifactId>webservices-tools</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>javax.xml</groupId>
<artifactId>webservices-extra-api</artifactId>
<version>2.1-b16</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>webservices-extra</artifactId>
<version>2.1-b16</version>
</dependency>
JNDI 查找
// get the deployed name from startup log for each EJBs deployed
deployedName = "java:global/example-ear-2.0-SNAPSHOT/logic/ExampleBean!org.example.com.ExampleBean";
T ejb = (T) initialContext.lookup(deployedName);