How to access CXF jars from Wildfly (Jboss) for ws endpoints

The Coder picture The Coder · Apr 2, 2015 · Viewed 7.5k times · Source

I've tried to deploy my war file in Wildfly 8.2. My application uses org.apache.cxf for web service. But Wildfly (Jboss) comes by default with its own cxf jars which can be provide full Java EE support. I could eliminate jboss cxf and utilise my own cxf jars for web services by

jboss-deployment-structure.xml

<jboss-deployment-structure>
    <deployment>
        <exclude-subsystems>
            <subsystem name="webservices" />
        </exclude-subsystems>
    </deployment>
</jboss-deployment-structure>

But it'll disable ws support by jboss which means I can't even find ws endpoints in Jboss admin console. But my client needs to utilise jboss's build in ws features so that he can disable or enable any ws calls at any time. Does anyone know on how to configure my application to utilise jboss's cxf jars so that I can tune my ws in Jboss admin console at any time. The following link explains exactly the same which I've mentioned so far. I'm successfull with the first option, but I need it to work with second option.

http://cxf.apache.org/docs/application-server-specific-configuration-guide.html

Note: See the first topic ( JBoss Application Server )

I can't seem to figure out how I can configure my application to utilise jboss's cxf jars..!

If I remove all the org.apache.cxf dependencies from my build.gradle file, it give ClassNotFoundException error which infact tells me that it can find the cxf-transport jar.

Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.ClassNotFoundException: org.apache.cxf.transport.servlet.CXFServlet

If I include org.apache.cxf dependenices in build.gradle file, it shows that it's conflicting with the cxf jar which is also present in Jboss. The whole problem is I need to utilise the cxf which is present in jboss for full Java EE support by eliminating the user defined cxf jars.

Answer

zhrist picture zhrist · Feb 29, 2016

This is probably overlap with some other dependency what implies different version.

I had the same situation and had to test and remove all un-nesesery ones from org.apache.cxf, especially deprecated ones like:

  • cxf-rt-rs-extension-providers,
  • cxf-distribution-manifest,
  • cxf-bundle-jaxrs and
  • cxf-rt-frontend-jaxrs.

It is important for keeping compatibility to use ${cxf.version} for all org.apache.cxf, especialy for later versions and check the dependency hierarchy if other dependencies are bringing in older cxf libraries.