JBoss Application Server (JBoss AS) comes with its own webservices stack (JBossWS) in order for providing full JavaEE support; that is currently internally based on Apache CXF. When willing to run Apache CXF based applications on top of JBoss AS 7 series, users have basically two options:

• use JBoss AS as if it was a servlet container with no WS functionalities: this basically implies disabling the webservices subsystem for the user deployment, hence preventing the AS webservices stack from processing the ws endpoint deployment and letting the CXF libs included in the archive deal with any WS invocations when CXFServlet is hit; the webservices subsystem is turned off by adding a jboss-deployment-structure.xml as follows to the ws endpoint deployment:

   

  <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
      <deployment>
          <exclude-subsystems>
              <subsystem name="webservices" />
          </exclude-subsystems>
      </deployment>
  </jboss-deployment-structure>
  
  

  this approach offers the fastest route to deploying CXF apps on JBoss AS; the drawback is that no special ws integration with JBoss AS internals is available

• rely on JBossWS integration and the Apache CXF libraries included in the application server (documentation): this implies removing any Apache CXF libs from the ws deployment as well as any other dependencies which is already included in JBoss AS (including any Java EE API jar); if included, the optional web.xml descriptor is to be rewritten according to JBossWS convention (see documentation); the Spring support is optional in JBoss AS and Spring based endpoint declaration is not the default/preferred configuration approach for ws endpoints, hence users willing to declare endpoints using Spring needs to create a org.springframework.spring module and put their endpoint declarations in a jbossws-cxf.xml descriptor; if the user application makes use of any lib besides tha JavaEE api, proper module dependencies are to be declared either using the jboss-deployment-structure.xml descriptor or the archive MANIFEST.MF (few directions on ws modules available here)

The second approach is the recomended one (and supported on EAP) and allows leveraging the full JavaEE 6 stack (including e.g. JSR-109) as well as specific ws integration with JBoss AS internals (full EJB3 endpoint support, JAAS integration, JBossWS configuration / management additions, CDI, etc.).

The mentioned JBWS-3544 bug was fixed in JBossWS 4.1.0.Final.

Just FYI, what you did is completely disabling the webservices subsystem on the server. That is equivalent to having the jboss-deployment-structure.xml descriptor mentioned above in any deployment.

Btw, some doc on this available at https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7

Hi asoldano,

While migrating application from JBoss AS7 to WildFly9 I got following exception :

."diamond-ws.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."diamond.ear"."diamond-ws.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "diamond-ws.war" of deployment "diamond.ear"

               at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)

               at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)

               at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)

               at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

               at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

               at java.lang.Thread.run(Thread.java:745)

Caused by: org.jboss.wsf.spi.WSFException: WFLYWS0066: Servlet class org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet declared in web.xml; either provide a proper deployment relying on JBossWS or disable the webservices subsystem for the current deployment adding a proper jboss-deployment-structure.xml descriptor to it. The former approach is recommended, as the latter approach causes most of the webservices Java EE and any JBossWS specific functionality to be disabled.

               at org.jboss.as.webservices.tomcat.WebMetaDataModifier.configureEndpoints(WebMetaDataModifier.java:98)

               at org.jboss.as.webservices.tomcat.WebMetaDataModifier.modify(WebMetaDataModifier.java:63)

               at org.jboss.as.webservices.tomcat.WebMetaDataModifyingDeploymentAspect.start(WebMetaDataModifyingDeploymentAspect.java:38)

               at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)

               at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)

               ... 5 more

Snippet from web.xml is as follows:

<servlet>

  <servlet-name>CXFServlet</servlet-name>

  <display-name>CXF Servlet</display-name>

  <servlet-class>org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet</servlet-class>

  <init-param>

  <param-name>javax.ws.rs.Application</param-name>

  <param-value>

  com.perotsystems.diamond.ws.rs.DiamondRESTWebServiceConfig      

  </param-value>

  </init-param>

  <init-param>

  <param-name>jaxrs.properties</param-name>

  <param-value>

  check.parameter.handlers.first=true attachment-directory=/tmp attachment-memory-threshold=404800 attachment-max-size=404800

  </param-value>

  </init-param>

  </servlet>

  <servlet-mapping>

  <servlet-name>CXFServlet</servlet-name>

  <url-pattern>/rest/*</url-pattern>

  </servlet-mapping>

I would like to use JBossWS instead of external CxF. By the way I also tried disabling webservices feature by commenting webservices extension module and subsystem as described above and that also didn't work. Could you please advise the way out?

Thanks!!