Apache CXF and JBossWS both provide an implementation of javax.xml.ws.spi.Provider, which is basically the entry point for a JAX-WS client API implementation.
As a consequence, unless endorsing is expected to be used, the JBossWS jars need to come before the Apache CXF ones when defining a flat classpath meant to be used by JAX-WS clients applications.
Currently, the WildFly integration testsuite relies on a flat classpath derived from the maven dependency tree of org.wildfly:wildfly-feature-pack, which hence need to be properly tuned.
This is of course not a problem at all in-container on WildFly, as proper module dependencies are already in place and defining the classloaders. Same reasoning applies for those relying on the org,jboss.ws.cxf:jbossws-cxf-client dependency only (as that pulls the whole JBossWS-CXf and Apache CXF dependency tree in the proper order), instead of explicitly declaring single dependencies without allowing transitive dependencies (as it's done in wildfly-feature-pack).