Causado por: java.lang.NoClassDefFoundError: org / apache / log4j / Logger

Tengo un problema interesante en el que la clase org.apache.log4j.Logger no se encuentra durante el tiempo de ejecución. Estoy tratando de obtener autorización y ahí es donde está fallando:

OAuthAuthorizer oauthAuthorizer = new OAuthAuthorizer(OAUTH_CONSUMER_KEY, OAUTH_CONSUMER_SECRET, SAML_PROVIDER_ID, userId);

Estoy usando JDeveloper 11.1.1.6. Esto es lo que sé:

  1. He buscado en mi directorio UI.war / WEB-INF / lib y veo log4j-1.2.17.jar allí.

  2. La clase que se queja es org.opensaml.xml.XMLConfigurator

     Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger at org.opensaml.xml.XMLConfigurator.(XMLConfigurator.java:60) at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:195) at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:91) at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.getSAMLBuilder(SAML2AssertionGenerator.java:156) at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.createSubject(SAML2AssertionGenerator.java:187) at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.buildAssertion(SAML2AssertionGenerator.java:114) at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.generateSignedAssertion(SAML2AssertionGenerator.java:83) at com.intuit.ipp.aggcat.util.SamlUtil.createSignedSAMLPayload(SamlUtil.java:156) at com.intuit.ipp.aggcat.util.OAuthUtil.getOAuthTokens(OAuthUtil.java:60) at com.intuit.ipp.aggcat.core.OAuthAuthorizer.(OAuthAuthorizer.java:85) at com.incomemax.view.intuit.WebUtil.getAggCatService(WebUtil.java:91) 
     Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:305) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:246) ... 64 more 
  3. Descompuesto XMLConfigurator y, curiosamente, no importa org.apache.log4j.Logger. Utiliza org.slf4j.Logger, que también está en mi directorio jars (slf4j-api-1.7.5.jar). También es interesante que la línea 60 (ver el seguimiento de la stack) es una línea en blanco en mi descomstackción.

  4. Por supuesto, si agrego Logger.xxxxx durante el tiempo de diseño, lo encuentra muy bien.

  5. Estoy usando el código / jar directamente desde el código de Java de ejemplo, pero importado a mi aplicación existente.

He estado buscando por la web en busca de respuestas y creo que he verificado todas las áreas en las que puedo pensar. También hice referencia a esta muy buena página: http://myarch.com/classnotfound/

Dada la autorización es el paso 1 en el uso de la API de desarrollo Intuit, estoy un poco atascado.

Agregar salida de @jhadesdev sugerencia:

Todas las versiones de log4j Logger:

  • zip: C: /Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/log4j-1.2 .17.jar! /Org/apache/log4j/Logger.class

Todas las versiones de log4j visibles desde el cargador de clases de la clase OAuthAuthorizer:

  • zip: C: /Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/log4j-1.2 .17.jar! /Org/apache/log4j/Logger.class

Todas las versiones de XMLConfigurator:

  • jar: file: / C: /Oracle/Middleware11116/modules/com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar! /org/opensaml/xml/XMLConfigurator.class

  • zip: C: /Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/ipp-java -aggcat-v1-devkit-1.0.2.jar! /org/opensaml/xml/XMLConfigurator.class

  • zip: C: /Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/xmltooling-1.3 .1.jar! /Org/opensaml/xml/XMLConfigurator.class

Todas las versiones de XMLConfigurator visibles desde el cargador de clases de la clase OAuthAuthorizer:

  • jar: file: / C: /Oracle/Middleware11116/modules/com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar! /org/opensaml/xml/XMLConfigurator.class

  • zip: C: /Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/ipp-java -aggcat-v1-devkit-1.0.2.jar! /org/opensaml/xml/XMLConfigurator.class

  • zip: C: /Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/xmltooling-1.3 .1.jar! /Org/opensaml/xml/XMLConfigurator.class

Todavía estoy trabajando en la interpretación de los resultados.

Durante el tiempo de ejecución, su aplicación no puede encontrar el contenedor.

Tomado de esta respuesta por Jared :

Es importante mantener dos excepciones diferentes directamente en nuestra cabeza en este caso:

  1. java.lang.ClassNotFoundException Esta es una Exception , indica que la clase no se encontró en el classpath. Esto indica que estábamos tratando de cargar la definición de la clase, y la clase no existía en la ruta de clases.

  2. java.lang.NoClassDefFoundError Esto es un Error , indica que la JVM buscó en su estructura de datos de definición de clase interna la definición de una clase y no la encontró. Esto es diferente a decir que no se pudo cargar desde classpath. Por lo general, esto indica que previamente intentamos cargar una clase desde la ruta de clases, pero falló por algún motivo; ahora lo intentamos de nuevo, pero ni siquiera intentaremos cargarlo, porque no lo cargamos antes. La falla anterior podría ser una ClassNotFoundException o un ExceptionInInitializerError (que indica una falla en el bloque de inicialización estática) o cualquier cantidad de otros problemas. El punto es que un NoClassDefFoundError no es necesariamente un problema de classpath.

para similitudes y diferencias

Puede usar la siguiente dependencia maven en su archivo pom. De lo contrario, puede descargar los siguientes dos jar de la red y agregarlo a su ruta de comstackción.

  org.slf4j slf4j-api 1.6.4   org.slf4j slf4j-log4j12 1.6.4  

Esto se copia de mi proyecto de trabajo. Primero asegúrate de que esté funcionando en tu proyecto. Luego puede cambiar las versiones para usar cualquier otro (versiones) jar compatible.

Para AggCat, puede consultar el archivo POM de la aplicación java de muestra.

https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/CustomerAccountData/Java/AggCatSampleApplication/pom.xml

Gracias

En función de stacktrace, una clase de intuición com.intuit.ipp.aggcat.util.SAML2AssertionGenerator necesita un jar de saml en el classpath.

Una clase saml org.opensaml.xml.XMLConfigurator necesita en su turno log4j, que está dentro del WAR pero no puede encontrarlo.

Una explicación para esto es que la clase XMLConfigurator que necesita log4j no se encontró dentro del WAR sino en un cargador de clases downstream. ¿Podría un tarro saml faltar en la GUERRA?

La clase XMLConfigurator que necesita log4j no puede encontrarlo en el nivel del cargador de clases que lo cargó, y la versión log4j en WAR no está visible en ese cargador de clases en particular.

Para solucionar esto, una forma es agregar esto antes de la llamada a oauth:

 System.out.println("all versions of log4j Logger: " + getClass().getClassLoader().getResources("org/apache/log4j/Logger.class") ); System.out.println("all versions of XMLConfigurator: " + getClass().getClassLoader().getResources("org/opensaml/xml/XMLConfigurator.class") ); System.out.println("all versions of XMLConfigurator visible from the classloader of the OAuthAuthorizer class: " + OAuthAuthorizer.class.getClassLoader().getResources("org/opensaml/xml/XMLConfigurator.class") ); System.out.println("all versions of log4j visible from the classloader of the OAuthAuthorizer class: " + OAuthAuthorizer.class.getClassloader().getResources("org/apache/log4j/Logger.class") ); 

Además, si está utilizando Java 7, eche un vistazo a jHades , es una herramienta que hice para ayudar a solucionar este tipo de problemas.

Para ver qué está pasando, ¿podría publicar los resultados de las consultas de ruta de clases anteriores, para qué contenedor está sucediendo esto, tomcat, embarcadero? Sería mejor poner toda la stack de astackmiento con todas las causas por las que está en pastebin, por si acaso.

Comprobar el assembly de despliegue,

Tengo el mismo error, cuando genero el archivo war con la instalación “maven clean install” y lo despliego a mano, funciona bien, pero cuando uso el entorno de tiempo de ejecución (eclipse) surgen los problemas.

La solución para mí (para eclipse IDE) vaya a: “propiedades de proyecto” -> “Implementación de implementación” -> “Agregar” -> “el contenedor que necesita”, en mi caso java “entradas de comstackción de ruta”. Tal vez puede ayudar un poco!

Con las sugerencias @jhadesdev y las explicaciones de otros, he encontrado el problema aquí.

Después de agregar el código para ver qué era visible para los diversos cargadores de clase, encontré esto:

 All versions of log4j Logger: zip:war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class All versions of log4j visible from the classloader of the OAuthAuthorizer class: zip:war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class All versions of XMLConfigurator: jar:com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar!/org/opensaml/xml/XMLConfigurator.class zip:war/WEB-INF/lib/ipp-java-aggcat-v1-devkit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class zip:war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class All versions of XMLConfigurator visible from the classloader of the OAuthAuthorizer class: jar:com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar!/org/opensaml/xml/XMLConfigurator.class zip:war/WEB-INF/lib/ipp-java-aggcat-v1-devkit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class zip:war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class 

Noté que posiblemente otra versión de XMLConfigurator fuera recogido. Descompilé esa clase y encontré esto en la línea 60 (donde el error estaba en la traza original de la stack) private static final Logger log = Logger.getLogger(XMLConfigurator.class); y esa clase estaba importando de org.apache.log4j.Logger !

Entonces esta clase se estaba cargando y usando. Mi solución fue cambiar el nombre del archivo jar que contenía este archivo, ya que no puedo encontrar dónde lo carga explícita o indirectamente. Lo cual puede ser un problema cuando realmente despliegue.

Gracias por toda la ayuda y la muy necesaria lección sobre la carga de clases.

Tenía el mismo problema, de hecho fue causado por weblogic estúpidamente usando su propia implementación de opensaml. Para resolverlo, debe indicarle que cargue las clases desde WEB-INF/lib para este paquete en weblogic.xml :

   org.opensaml.*  

tal vez true también funcionaría.

java.lang.ClassNotFoundException indica que la clase no se encuentra en la ruta de clase. podría ser la versión de log4j no es compatible. verifique la diferente versión de log4j.