web services - example - Cliente de servicio web CXF: "No se puede crear un XMLInputFactory seguro"

spring cxf web service example

Question

Escribí e implementé un servicio web CXF en un servidor Tomcat siguiendo las instrucciones que se encuentran here . El servicio web se despliega bien, ya que puedo ver el archivo WSDL en un navegador web.

Sin embargo, mi programa de cliente Java independiente no funciona. Aquí está el código:

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");

Copié todos los archivos jar (incluido el archivo woodstox-core-asl-4.2.0.jar) de la distribución CXF 2.7.7 en el classpath del programa del cliente, y cuando ejecuto el cliente obtengo la siguiente excepción:

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

Encontré una página que dice que "No se puede crear un XMLInputFactory seguro" se puede arreglar configurando la propiedad org.apache.cxf.stax.allowInsecureParser en "1", por lo que traté de configurarlo en las propiedades del sistema, pero no no funciona También intenté agregar -Dorg.apache.cxf.stax.allowInsecureParser = 1 al comando java que ejecuta el cliente, pero tampoco funcionó. (Tampoco lo configuró como "verdadero" en lugar de 1.) ¿Alguna idea sobre cómo resolver este error?

Answer 1

1: -Dorg.apache.cxf.stax.allowInsecureParser = 1 para el JAVA_OPTIONS
o
2: cambia el nombre de woodstox-core-asl-4.4.1.jar -> awoodstox-core-asl-4.4.1.jar

Answer 2

De mi parte, tuve que eliminar el stax-api-1.0-2.jar (dejando stax2-api-3.1.4.jar y woodstock 4.4 jar) y especificarlo en el weblogic-application.xml al final. :

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

Answer 3

Desde la versión 2.7.4, CXF agregó una característica para garantizar que XMLInputFactory esté asegurado y cargado desde los paquetes de woodstox (> = 4.2.x, consulte la implementación de StaxUtil ) para enfrentar una vulnerabilidad de denegación de servicio.

Pero el hecho es que en un entorno J2EE, de forma predeterminada, webservices-rt.jar tiene la prioridad sobre las webservices-rt.jar guerra (y luego sobre el tarro de Woodstock). Por eso se carga la implementación no segura, lo que desencadena la excepción.

Desactivar la propiedad org.apache.cxf.stax.allowInsecureParser, no es una opción, ya que trae de vuelta la vulnerabilidad de DOS.

Para que el cargador de clases prefiera woodstox (ear / war lib) sobre webservices-rt.jar (j2ee lib), la solución depende de su servidor de aplicaciones y se describe en la guía de configuración específica del servidor de aplicaciones CXF.

Answer 4

El problema fue que faltan algunos archivos jar CXF en el despliegue del servicio web en el servidor. Esto fue difícil de depurar porque no había errores en el servidor.

Answer 5

En mi caso había dos frascos (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: compilar

Retiré el primero y empezó a funcionar.

Answer 6

Encontré este problema y se debió a que, cuando actualicé una versión anterior de cxf, no cambié stax-api - *. Jar a stax2-api - *. Jar en el classpath de mi cliente.

Answer 7

No hubo una respuesta aquí que describa la causa raíz de este mensaje de error para mi problema. Teníamos dependencias transitivas tanto en una nueva versión woodstox-core-asl-4.2.0.jar como en la versión anterior wstx-asl-3.2.1.jar.

Excluyendo la versión antigua de nuestra compilación hizo el truco.

Si profundiza en las entrañas de la versión anterior, encontrará que falla con una excepción que termina envuelta en otra excepción con este mensaje genérico que no es muy informativo.

Answer 8

Puedo resolver este problema agregando weblogic.xml en la carpeta WEB-INF de mi aplicación con el siguiente código:

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

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

Answer 9

Revisé mis dependencias para encontrar conflictos de versión con woodstox o stax-api.

Resulta que axis2-transport-http introdujo estos conflictos.

Si también tiene esta dependencia, agregue la siguiente exclusión a su dependencia pom que la introdujo

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

Answer 10

Si actualiza a 3.0.0 o posterior, no debe agregar dependencias de Woodstock

Answer 11

Tuve el mismo problema cuando actualicé CXF a 2.7.x. Resolví esto agregando las siguientes dependencias en 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>

Answer 12

Tuve este problema en weblogic y lo arreglé agregándolo a my weblogic-application.xml

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

Answer 13

Tuve este problema en weblogic, la aplicación se implementó con éxito, pero cuando disparé la solicitud de jabón, tuve este error: no se puede crear un XMLInputFactory seguro.

solucionó el problema agregando este paquete a weblogic-application.xml

com.ctc.wstx. *

Answer 14

Tuve un problema similar

Después de agregar este -Dorg.apache.cxf.stax.allowInsecureParser=1 al JAVA_OPTIONS en setDomainEnv.sh , está funcionando bien ahora.

Answer 15

Tuvo este problema al actualizar de CXF 2.3.x a 2.7.x

Se agregaron los tarros stax2-api y woodstox-core-asl de la distribución CXF de 2.7.x y el servicio web vuelve a funcionar.

Answer 16

Verifique que no haya otras versiones de woodstox que se encuentren en la ruta de clase o en la publicación / aprobación de jre o similar. Parece que una versión 4.1 más antigua puede ser recogida.