Yo soy la implementación de una aplicación Apache CXF-2.7.5 con neethi-3.0.2 en
websphere 7. Estoy recibiendo por debajo de error. Mi Solicitud es impulsado primavera.
Cuando me degradado Apache CXF para apache CXF-2.3.5. La aplicación con éxito
implementado.

El mismo funciona a la perfección en Tomcat7.

Soy capaz de reproducir este problema en Tomcat mediante la adición (o invalidar) una dependencia de neethi.jar (con una versión anterior –> 2.5.x) en pom.xml archivo.

Nota: Apache CXF 2.7.5 viene con una versión más reciente de neethi.jar (3.0.2), por lo tanto no causan problema en Tomcat7.

Es la Web de esfera recoger una versión anterior de neethi.jar

Seguimiento de la pila de es el siguiente :

[7/9/13 19:46:38:577 GMT+05:30] 00000012 FfdcProvider  I com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/ffdc/server1_2a7e2a7e_13.07.09_19.46.38.57558021.txt com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest() 309
[7/9/13 19:46:38:582 GMT+05:30] 00000012 webapp        E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[CXFServlet]: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cxf' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.bus.spring.SpringBus]: Constructor threw exception; nested exception is org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:997)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:943)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1588)
at com.ibm.ws.webcontainer.webapp.WebApp.commonInitializationFinish(WebApp.java:350)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:292)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:99)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:167)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:722)
Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.bus.spring.SpringBus]: Constructor threw exception; nested exception is org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:162)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:76)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:990)
... 35 more
Caused by: org.apache.cxf.bus.extension.ExtensionException: Could not load extension class org.apache.cxf.ws.policy.AssertionBuilderRegistryImpl.
at org.apache.cxf.bus.extension.Extension.tryClass(Extension.java:173)
at org.apache.cxf.bus.extension.Extension.getClassObject(Extension.java:185)
at org.apache.cxf.bus.extension.ExtensionManagerImpl.activateAllByType(ExtensionManagerImpl.java:138)
at org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus.java:126)
at org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus.java:138)
at org.apache.cxf.bus.spring.SpringBus.<init>(SpringBus.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:45)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:39)
at java.lang.reflect.Constructor.newInstance(Constructor.java:515)
at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:147)
... 37 more
Caused by: java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:265)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:726)
at com.ibm.ws.classloader.CompoundClassLoader.localFindClass(CompoundClassLoader.java:645)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:468)
at java.lang.ClassLoader.loadClass(ClassLoader.java:609)

Por favor, ayudar

OriginalEl autor Bhuvan | 2013-07-10

5 Comentarios

  1. 4

    Tuve que hacer ‘parent_last de la clase de carga en la web de nivel de módulo y eliminar los siguientes archivos jar de la GUERRA:-

    geronimo-servlet_3.0_spec-1.0.jar
    geronimo-javamail_1.4_spec-1.7.1.jar
    stax-api-1.0.1.jar

    Esto es debido a la AssertionBuilderFactory fue una aplicación en versión 2.0.5 de neethi.jar pero es una interfaz en 3.0.2 que estamos utilizando, debido a CXF 2.7.5.

    Ya que estos archivos jar se agregan automáticamente en tiempo de compilación debido a CXF dependencias, creo que vamos a tener que eliminar manualmente estos frascos de GUERRA antes de la implementación en la ERA. También con cada implementación, vamos a tener que cambiar de Clase Gestor de configuración de nuestra GUERRA.

    Para cambiar el Cargador de Clase de la orden, use la siguiente ruta de acceso:-
    Las Aplicaciones de la empresa > MyApplicationWAR > Administrar Módulos > MyApplicationWAR

    EDICIÓN:

    Usted puede hacer lo mismo de su POM archivo con <exclusions> etiqueta

    <dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-bundle-jaxrs</artifactId>
    <version>${cxf.version}</version>
    <exclusions>
    <exclusion>
    <groupId>org.apache.geronimo.specs</groupId>
    <artifactId>geronimo-javamail_1.4_spec</artifactId>
    </exclusion>
    <exclusion>
    <groupId>org.apache.geronimo.specs</groupId>
    <artifactId>geronimo-servlet_3.0_spec</artifactId>
    </exclusion>
    </exclusions>
    </dependency>
    <!-- Jettison Dependency -->
    <dependency>
    <groupId>org.codehaus.jettison</groupId>
    <artifactId>jettison</artifactId>
    <version>${jettison.version}</version>
    <exclusions>
    <exclusion>
    <groupId>stax</groupId>
    <artifactId>stax-api</artifactId>
    </exclusion>
    </exclusions>
    </dependency>
    Creo que se podría quitar estas dependencias de forma automática utilizando el <exclusions> etiqueta en su maven dependencia de la definición. Que sería mucho más fácil de quitar de forma manual desde la guerra de archivo.
    Sí tienes razón. También hice de esa manera. La actualización de la respuesta
    intenta configurar el JVM de la aplicación servidor para uso de los padres-última clase de carga?
    No, el resolvieron mi problema. Yo no estoy trabajando en ese proyecto.

    OriginalEl autor Bhuvan

  2. 2

    Sí, es posible que SE es tener una versión anterior de neethi.

    Usted debe comprobar la carpeta lib de websphere para ver si hay una versión antigua de neethi tarro allí. Usted también puede necesitar para configurar el contenedor para permitir la auto-primera classloading manera si hay neethi versión conflicto.

    Otra opción es implementar la necesaria neethi.jar en refrendado directorio y, a continuación, iniciar la VM con los parámetros adecuados.

    OriginalEl autor Mubin

  3. 0

    Sugiero que pruebe la configuración de la clase gestor de propiedades de la ERA.
    Configurarlo para que sea de aplicación cargador de clase en primer lugar de los padres de la clase loader. Con esto, SE va a recoger la jarra que se han empaquetado dentro de la aplicación. HTH

    OriginalEl autor paary

  4. 0

    ¿Cuál es el impacto de la eliminación de los siguientes tres frascos tienen en la solución del problema? Tengo un problema similar pero con una prueba de junit en lugar de correr en la ERA. Tengo neethi-3.0.1.jar y cxf-rt-core-2.7.4.jar en mi pom. Sin embargo, yo todavía java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
    en la org.apache.cxf.el autobús.la extensión.La extensión de
    así que yo supongo que de alguna manera, estoy todavía dispone de una versión anterior de neethi en el classpath.
    ¿Cómo puedo solucionarlo?
    geronimo-servlet_3.0_spec-1.0.jar
    geronimo-javamail_1.4_spec-1.7.1.jar
    stax-api-1.0.1.jar

    Bienvenido a stackoverflow. Esto en realidad no responder a la pregunta; me gustaría sugerir la apertura de una nueva pregunta y si usted piensa que va a ayudar, vinculando a éste para que de fondo.
    He presentado una nueva pregunta.

    OriginalEl autor jimmy

  5. -2

    Poner la última versión neethi.jar en el aprobado directorio dentro de ti Websphere Java para una solución rápida, reinicie el JVM y probarlo.

    Eso es una mala solución, ya que puede tener efectos secundarios inesperados en el WebSphere tiempo de ejecución. La solución correcta es establecer el cargador de clase de la política de la aplicación de padres del pasado.

    OriginalEl autor Sandeep Raman

Dejar respuesta

Please enter your comment!
Please enter your name here