CXF web service client: "Cannot create a secure XMLInputFactory"

Question

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.

My standalone Java client program doesn't work though. Here is the code:

System.out.println("Creating client");
Properties properties = System.getProperties();
properties.put("org.apache.cxf.stax.allowInsecureParser", "1");
System.setProperties(properties);
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(ExampleWebService.class);
factory.setAddress("http://X.X.X.X:9090/WebServices/ExampleWebService");
ExampleWebService exampleWebService = (ExampleWebService)factory.create();
System.out.println("Done creating client");
exampleWebService.method1("test");
System.out.println("After calling method1");

I copied all the jar files (including the woodstox-core-asl-4.2.0.jar file) from the CXF 2.7.7 distribution into the client program's classpath, and when I run the client I get the following exception:

Creating client
Nov 20, 2013 8:05:26 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://webservices.server/}ExampleWebServiceService from class server.webservices.ExampleWebService
Done creating client
javax.xml.ws.soap.SOAPFaultException: Cannot create a secure XMLInputFactory
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
    at $Proxy38.printString(Unknown Source)
    at ExampleNmsWebServiceClient.printString(ExampleNmsWebServiceClient.java:29)
    at ExampleNmsWebServiceClient.main(ExampleNmsWebServiceClient.java:40)
Caused by: org.apache.cxf.binding.soap.SoapFault: Cannot create a secure XMLInputFactory
    at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84)
    at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51)
    at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
    at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113)
    at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
    at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
    at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:835)
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1502)
    at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1309)
    at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
    at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
    at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
    at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
    at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
    at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
    at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
    at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
    ... 3 more

I found a page saying the "Cannot create a secure XMLInputFactory" can be fixed by setting the org.apache.cxf.stax.allowInsecureParser property to "1", which is why I tried to set it in the System properties, but that didn't work. I also tried to add -Dorg.apache.cxf.stax.allowInsecureParser=1 to the java command that runs the client, but that didn't work either. (Nor did setting it to "true" instead of 1.) Any ideas on how to solve this error?

Functionary

Answer 1

Had this problem when upgrading from CXF 2.3.x to 2.7.x

Added stax2-api and woodstox-core-asl jars from the 2.7.x CXF distribution and the webservice works again.

Coralloid

5 years later in 2019, I had this problem with CXF 3.3.3. In addition to adding the two dependencies, I also needed to EXCLUDE other stax-api and woodstox and wstx libraries from other dependencies that included old versions of those. The maven target dependency:tree helped me to figure this out. – Rakia

Answer 2

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

Horseman

+1 for the most complete explanation, allowInsecureParser is fine for me though, as I need it just for local debugging. – Valediction

Does Tomcat need this class loader ordering? – Palembang

I have never needed class loader ordering on tomcat 7 oder 8.5 with CXF. – Vendible

Answer 3

I had similar problem

After adding this -Dorg.apache.cxf.stax.allowInsecureParser=1 to the JAVA_OPTIONS in setDomainEnv.sh, It is working fine now.

Jenninejennings

I resorted to this solution as well. In my case the problem was that when StaxUtils tries to get a new XMLInputFactory (XMLInputFactory.newInstance();) it got the WstxInputFactory from my webservices-rt-2.3.jar, and not the secure version from woodstox-core-asl-4.4.1.jar. Unfortunately I needed the webservices-rt for other code, so had to resort to using this solution. Apache CXF can be such a headache when it comes to dependency conflicts. – Kerek

Answer 4

I had this problem on weblogic and fixed the problem by adding this to my weblogic-application.xml

<prefer-application-packages>
       <package-name>com.ctc.wstx.*</package-name>
</prefer-application-packages>

Mattern

how can achieve the same in jboss as 7.1.1.Final...any idea? – Carreno

Just a side note: the package com.ctc.wstx.* is used by woodstox-core-asl which is pulled by cxf-api. – Tripterous

Answer 5

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.

Downturn

There's only the one woodstox-core-asl-4.2.0.jar that I mentioned in my client's classpath, and I cannot find any woodstox* within my JRE's lib directory. – Functionary

Yes! I found that somehow get to my Tomcat woodstox-core-asl-4.4.1.jar and woodstox-core-asl-4.1.2.jar at same time. Just delete old version and everything now works. – Stichomythia

Answer 6

There was not an answer here that describes the root cause of this error message for my issue. We had transitive dependencies on both a new version woodstox-core-asl-4.2.0.jar and and old wstx-asl-3.2.1.jar

Excluding the old version from our build did the trick.

If you dig into the bowels of the old version, you'll find that it fails with an exception that ends up getting wrapped in another exception with this generic message that is not very informative.

Thrombin

Good answer! I discovered this error only on our productive system and wasn't able to reproduce it locally. After reading your comment I was able to reproduce and fix it. Saved my day! – Megohm

The same war worked fine in my local windows machine TC Server tomcat 8, but when deployed to UNIX machine it failed. Removing the old version of wstx-asl.***.jars it solved the issue – Animato

We were using Apache CXF 3.1.10 to call a web service in an app running on JBoss 6.4. On my local Windows machine, the service call worked fine. However, in our QA environment, we were seeing the “Cannot create a secure XMLInputFactory” error. The WAR file had both woodstock-core-asl-4.2.0.jar and wstx-asl-3.2.9.jar as dependencies in the WEB-INF/lib folder. I removed the wstx-asl-3.2.9.jar file, and the web service call worked as expected. Thanks so much for the answer. – Bronchi

Answer 7

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>

Gaudery

Answer 8

I hit this issue and it was because, when i upgraded from an older version of cxf, i did not change stax-api-*.jar to stax2-api-*.jar in my client classpath.

Aniline

Answer 9

If you upgrade to 3.0.0 or later, you shouldn't add woodstock dependencies

Mythomania

It's seems that this not truw where did you get this info? In the class WoodstoxHelper (3.1.11) they call Woodstox – Serosa

Answer 10

Interestingly I had this issue in docker container and not while running it on tomcat server.

The problem that I faced was that the project had another lower version of wstx-asl-3.2.7 and the class loader probably could have loaded this versions first. I got rid of it and the necessary woodstox was considered and the problem was solved.

Howlett

Answer 11

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.

Functionary

Do you have any idea which CXF files were missing? I'm having a very similar problem myself. – Wattage

Figured it out; I solved my issue by un-excluding org.apache.cxf:cxf-bundle-jaxrs. – Wattage

What files were missing? – Dowdy

Answer 12

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

Handle

Answer 13

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>

Zoes

Answer 14

I had this problem on weblogic, Application get Deployed Successfully but when i fired the soap-request then i got this fault : Cannot create a secure XMLInputFactory.

fixed the problem by adding this package to weblogic-application.xml

com.ctc.wstx.*

Gouge

Answer 15

I looked through my dependencies to find version conflicts with woodstox or stax-api.

Turns out that axis2-transport-http introduced these conflicts.

If you happen to have this dependency as well, add the following exclusion to your pom dependency that introduced it

<exclusions>
            <exclusion>
                <groupId>org.apache.axis2</groupId>
                <artifactId>axis2-transport-http</artifactId>
            </exclusion>
        </exclusions>

Tourbillion

Answer 16

I can solve this problem by adding weblogic.xml in the WEB-INF folder of my app with the following code:

<prefer-web-inf-classes>false</prefer-web-inf-classes>

<prefer-application-packages>
    <package-name>com.ctc.*</package-name>
</prefer-application-packages>

Homeopathic

Answer 17

1: -Dorg.apache.cxf.stax.allowInsecureParser=1 to the JAVA_OPTIONS
or
2: rename woodstox-core-asl-4.4.1.jar -> awoodstox-core-asl-4.4.1.jar

Keppel

Hi, please consider editing your answer to add more explanation which could help OP and anyone in the future struggling with a similar problem – Bootie