I am wrote and deployed a CXF web service into a Tomcat server using the instructions here. The web service deploys fine as I can see the WSDL file in a web browser.
<The problem was some missing CXF jar files in the web service deployment on the server. This was tough to debug because there were no errors on the server.
In my case there were two jars (Cxf 3.0.1, Jboss 7.1.1)
javax.xml.stream:stax-api:jar:1.0-2:compile
org.codehaus.woodstox:stax2-api:jar:3.1.4:compile
I removed the 1st one and it started working
from my end, I had to do both remove the stax-api-1.0-2.jar (leaving stax2-api-3.1.4.jar & woodstock 4.4 jar) and specify in the weblogic-application.xml at the end of it:
.
.
<package-name>com.ctc.wstx.*</package-name>
<package-name>org.codehaus.stax2.*</package-name>
</prefer-application-packages>
Since version 2.7.4, CXF added a feature in order to ensure that the XMLInputFactory is secured and loaded from woodstox (>= 4.2.x packages, see StaxUtil implementation) in order to deal with a Denial of Service vulnerability
But the fact is that in a J2EE environment, by default, webservices-rt.jar
has the priority over war libs (and then over the woodstock jar). That is why the non-secure implementation is loaded, triggering the exception.
Turning off the org.apache.cxf.stax.allowInsecureParser property, is not an option as it brings back the DOS vulnerability.
In order to make the class loader to prefer woodstox
(ear/war lib) over webservices-rt.jar
(j2ee lib), the solution depends on your application server and is described in CXF application server specific configuration guide
I had the same problem whenI upgraded CXF to 2.7.x. I resolved this by adding following dependencies in POM
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>stax2-api</artifactId>
<version>4.0.0</version>
</dependency>
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>woodstox-core-asl</artifactId>
<version>4.4.1</version>
</dependency>
Check for any other versions of woodstox that may be found on the classpath or in the jre's lib/endorsed or similar. It sounds like an older 4.1 version may be picked up.