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

Question

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 1

I'm answering this question because the link provided in the comment is not available anymore and it seems to have been the correct answer. Jboss Docs have been archived and this is the new link

https://docs.jboss.org/author/display/WFLY8/JBoss%20Modules%20and%20WS%20applications.html

In true StackOverflow fashion I'm copying the information contained in the page so that it doesn't get lost again:

The JBoss Web Services functionalities are provided by a given set of modules / libraries installed on WildFly, which are organized into JBoss Modules modules. In particular the org.jboss.as.webservices.* and org.jboss.ws.* modules belong to the JBossWS - WildFly integration. Users should not need to change anything in them.

While users are of course allowed to provide their own modules for their custom needs, below is a brief collection of suggestions and hints around modules and webservices development on WildFly. Setting module dependencies

On WildFly the user deployment classloader does not have any visibility over JBoss internals; so for instance you can't directly use JBossWS implementation classes unless you explicitly set a dependency to the corresponding module. As a consequence, users need to declare the module dependencies they want to be added to their deployment.

The JBoss Web Services APIs are always available by default whenever the webservices subsystem is available on AS7. So users just use them, no need for explicit dependencies declaration for those modules.

Using MANIFEST.MF

The convenient method for configuring deployment dependencies is adding them into the MANIFEST.MF file:

Manifest-Version: 1.0
Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services export,foo.bar

Here above org.jboss.ws.cxf.jbossws-cxf-client and foo.bar are the modules you want to set dependencies to; services tells the modules framework that you want to also import META-INF/services/.. declarations from the dependency, while export exports the classes from the module to any other module that might be depending on the module implicitly created for your deployment.

When using annotations on your endpoints / handlers such as the Apache CXF ones (@InInterceptor, @GZIP, ...) remember to add the proper module dependency in your manifest. Otherwise your annotations are not picked up and added to the annotation index by WildFly, resulting in them being completely and silently ignored.

Using JAXB

In order for successfully directly using JAXB contexts, etc. in your client or endpoint running in-container, you need to properly setup a JAXB implementation; that is performed setting the following dependency:

Dependencies: com.sun.xml.bind services export 

Using Apache CXF

In order for using Apache CXF APIs and implementation classes you need to add a dependency to the org.apache.cxf (API) module and / or org.apache.cxf.impl (implementation) module:

Dependencies: org.apache.cxf services

However, please note that would not come with any JBossWS-CXF customizations nor additional extensions. For this reason, and generally speaking for simplifying user configuration, a client side aggregation module is available with all the WS dependencies users might need.

Client side WS aggregation module

Whenever you simply want to use all the JBoss Web Services feature/functionalities, you can set a dependency to the convenient client module.

Dependencies: org.jboss.ws.cxf.jbossws-cxf-client services

Please note the services option above: that's strictly required in order for you to get the JBossWS-CXF version of classes that are retrieved using the Service API, the org.apache.cxf.Bus for instance.

Be careful as issues because of misconfiguration here can be quite hard to track down, because the Apache CXF behaviour would be sensibly different.

The services option is almost always needed when declaring dependencies on org.jboss.ws.cxf.jbossws-cxf-client and org.apache.cxf modules. The reason for this is in it affecting the loading of classes through the Service API, which is what is used to wire most of the JBossWS components as well as all Apache CXF Bus extensions. Using Spring

The JBossWS-CXF modules have optional dependencies to the org.springframework.spring module. So either create that manually in the application server or use the JBossWS-CXF installation scripts for doing that.

Annotation scanning

The application server uses an annotation index for detecting JAX-WS endpoints in user deployments. When declaring WS endpoints whose class belongs to a different module (for instance referring that in the web.xml descriptor), be sure to have an annotations type dependency in place. Without that, your endpoints would simply be ignored as they won't appear as annotated classes to the webservices subsystem.

Dependencies: org.foo annotations 

Using jboss-deployment-descriptor.xml

In some circumstances, the convenient approach of setting module dependencies in MANIFEST.MF might not work. An example is the need for importing/exporting specific resources from a given module dependency. Users should hence add a jboss-deployment-structure.xml descriptor to their deployment and set module dependencies in it.

Spring based in-container Bus creation

A noteworthy scenario requiring explicit module dependencies declaration is whenever a Spring beans descriptor based Bus is created by users in a in-container client. Spring basically resolves any beans declared in the descriptor (e.g. cxf.xml), as well as any transitively referenced internal CXF descriptor, using the thread context classloader. That is the classloader associated to the deployment, which is different from the classloader used by JBossWS internally. As a consequence, in this scenario a jboss-deployment-structure.xml as follows is required:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="org.jboss.ws.cxf.jbossws-cxf-client" services="import" />
<module name="org.apache.cxf.impl">
<imports>
<include path="META-INF"/>
<include path="META-INF/cxf"/>
</imports>
</module>
<module name="org.springframework.spring">
<imports>
<include path="META-INF"/>
</imports>
</module>
</dependencies>
</deployment>
</jboss-deployment-structure>

The first dependency (org.jboss.ws.cxf.jbossws-cxf-client) loads JBossWS customizations as well as Apache CXF APIs first. The second dependency (org.apache.cxf.impl) loads the Apache CXF internals (in particular the CXF SpringBus class), required by Spring to load the Bus using the deployment classloader. Finally, the third dependency (org.springframework.spring) is needed to allow resolution of Spring schemas when running offline.

Answer 2

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.