eclipse / tomcat: deploy ya no funciona (ClassNotFoundException)

Estoy ejecutando Eclipse Helios Service Release 1, con Tomcat 7.0.12 en Linux Ubuntu Natty Narwhal.

He estado felizmente re-implementando mi aplicación web hasta que dejó de funcionar aparentemente sin motivo. Se muestra la siguiente excepción:

SEVERE: Allocate exception for servlet Index java.lang.ClassNotFoundException: obliquid.servlet.Index at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) 
  • En la pestaña Servidores , tengo “Tomcat v7.0 Server at localhost [Started, Synchronized]
  • Mi proyecto aparece como un hijo del servidor Tomcat v7.0
  • En Propiedades, ruta de comstackción de Java, carpeta de origen I’ve Project / src Source
  • En Propiedades, Ensamblado de implementación web, tengo las siguientes asignaciones: / WebContent -> / , / src -> / WEB-INF / classes , / test -> / build / classes
  • Mi directorio src contiene un servlet en obliquid / servlet / Index.java
  • Intenté ya hacer clic en Clean Module Work Directory … y publicar
  • Traté de detener e iniciar el servidor desde la pestaña Servidores Eclipse

¿Qué más debo verificar? Gracias.

ACTUALIZACIÓN A pesar de que ahora estoy trabajando con el nuevo proyecto, volví para revisar el anterior, y misteriosamente ahora está funcionando. Creo que no podré encontrar lo que sucedió.

Sin embargo, hoy, con el nuevo proyecto, tuve 404 errores sin razón aparente y descubrí que hacer clic derecho en el servidor Tomcat y seleccionar “Limpiar …” puede ser útil. Tal vez podría haber ayudado.

Al seleccionar “Limpiar …”, dice: “Limpiar descartará todo estado de publicación y volver a publicar desde cero. ¿Está seguro de que quiere limpiar todos los recursos publicados?”. Al seleccionar sí, resolví el problema

ACTUALIZACIÓN 2 Sucedió nuevamente en el nuevo proyecto. Errores 404, esta vez no desaparecen.

 Stop -> Clean... -> Start (404) Stop -> Clean Tomcat Work Directory... -> Start (404) Stop -> Clean Tomcat Work Directory... -> Clean... -> Start (404) Stop -> Remove on the application -> Clean... -> Run As -> Run on Server -> (404) Exit Eclipse, Start Eclipse Start the server -> (404) 

ACTUALIZACIÓN 3 Resultó que esta vez simplemente no noté una excepción causada por una clase de escucha durante el inicio. Después de resolver el problema, funcionó. Supongo que debería dejar de trabajar a las 3 AM.

Mientras estaba en Tomcat 6 y Eclipse Ganimedes descubrí que la siguiente cadena funcionaba como un encanto:

1 servidor de parada

2 proyecto -> limpio

3 proyecto de comstackción (tuve la comstackción automática deshabilitada)

4 eliminar servidor

5 carpeta Eliminar servidores

6 reiniciar Eclipse

7 crea un nuevo servidor, agrega un proyecto y comienza 🙂

toma algo de tiempo, pero funcionó como el encanto. Mi problema era un problema irritante de inicio del Oyente, pero parece ser algo similar: una propiedad en Tomcat. Por cierto, hoy en día también soy un gran fan de Glassfish.

Encontré que este procedimiento es útil:

  • Haga clic en la pestaña Servidores y Detenga el servidor en uso si se está ejecutando
  • Haga clic derecho en el servidor de nuevo y seleccione Limpiar …
  • Haga clic con el botón secundario y seleccione Clean Tomcat Work Directory …

Esperemos que la ClassNotFoundException se haya ido ahora.

Otra vez tuve un problema con una clase lanzada al inicio del servidor, una excepción en una clase de escucha (ServletContextListener). Cuando un ServletContextListener genera una excepción durante el inicio, la implementación de la aplicación se cancela, de ahí los errores 404. En ese caso, al solucionar el problema que causó la excepción, la aplicación volvió a funcionar.

EDITAR : Este procedimiento más corto funcionó para mí la mayoría de las veces, pero hoy no funcionó y tuve que seguir el procedimiento extendido de Mico. Mi sugerencia es que, si tiene un problema similar, primero intente con este procedimiento más corto. Si el problema persiste, prueba con Mico’s.

Te recomendaría que detengas e inicies el servidor Tomcat nuevamente. La implementación en caliente no funciona para siempre; hay algunos problemas que harán que tengas que reiniciar después de algunas reubicaciones.

Me pregunto cuando veo la respuesta aceptada con +25 ¿ es realmente precisa ?

Primero, si va a eliminar el servidor, ¿qué sentido tiene limpiarlo? Tomará su tiempo innecesariamente y nada útil ganará.

Así que diré que solo 5, 6, 7 pasos deberían hacer la magia

5 carpeta Eliminar servidores

6 reiniciar Eclipse

7 crea un nuevo servidor, agrega un proyecto y comienza

Esto podría ser algo que aprendí en confesión 2011 . Para mí, esto suena como un problema de cargador de clases.

La teoría detrás:

  • Java no solo usa el tipo de la clase sino también el cargador de clases que lo cargó para identificar el tipo de una instancia. Esto significa que una operación simle podría fallar, por ejemplo

    ClassA a1 = nuevo a1; ClassA a2 = SomeOtherClass.giveMeInstanceOfA (); a1 = a2;

Este ejemplo fallaría si SomeOtherClass utiliza un cargador de clases diferente porque Java diría que no son lo mismo.

  • El orador también mencionó que algunos servidores usan por defecto alrededor de 45 cargadores de clases diferentes.

Qué significa esto en la práctica:

Despliega su aplicación web en el servidor, todo funciona bien. El servidor almacena en caché las clases y todo lo que necesita para cargarlas en algún lugar. Ahora crea un despliegue caliente y el servidor puede cargar nuevas clases con un cargador de clases nuevo (o diferente). Este es el punto donde comienza a ser peligroso porque a partir de ahora tienes dos clases diferentes en la memoria que deberían ser iguales. Las operaciones simples como moldes (ClassA a = (ClassA) new ClassA ()) fallan, los nuevos métodos dentro de la clase no se encuentran (porque el servidor toma una versión en caché sin este método), ….

Este es el punto en el que reinicio el servidor, limpio el directorio de trabajo (para deshacerse de las versiones en caché) y empiezo a pensar en la implementación en caliente como algo fundamental.

Si es posible probar el procedimiento de Mikkos y esto resuelve el problema, esta explicación podría ayudarlo a comprender por qué.

Sé que esto no resuelve tu problema, pero podría darte algunas pistas de lo que podría haber pasado.

He adquirido una nueva experiencia en progtwigción y ya no me muero de hambre con la combinación de Eclipse + Tomcat. Varias maneras aquí pueden ayudarlo a salir de la necesidad del uso de esa combinación:

Primero que nada, ¡no los uses juntos!

  • Puede usar otros IDEs disponibles, por ejemplo, IntellijIdea (que no es gratuito, pero vale la pena invertir) tiene una propiedad que cuando depura un código Java, puede cambiar el código on fly y comstackr los archivos Java uno por uno y luego sugiere si desea tenerlo actualizado en el servidor. No es necesario reiniciar casi nunca (por supuesto, a veces se pierde, pero principalmente funciona).

  • Utilice el servidor Tomcat independiente, no el que está dentro de Eclipse / su IDE. Ese primer truco funciona solo cuando depura el servidor externo, nada dentro de IDE. Llega el segundo consejo: si cambias solo el contenido jsp o html, esos archivos pueden copiarse en el lugar correcto dentro de la carpeta webapp de tomcat manualmente con unix cp o el comando de copia de Windows y si desarrollas archivos en el mismo largo tiempo , puede copiar el contenido de la carpeta (por ejemplo, myFolder / *. jsp) tantas veces como desee y no se necesita reiniciar en absoluto. Los cambios aparecen cuando toca, edita y guarda el archivo web.xml dentro de la carpeta webapps y luego luego de actualizar la página visible en el navegador. Probablemente una actualización difícil con CTRL + F5 es la mejor manera.

Gracias a @Verdan por su comentario, de lo contrario no habría vuelto a responder.

Hablando de la implementación en caliente de Tomcat, de hecho experimentarás varios problemas, el menor de los cuales es la pérdida de memoria, por lo que deberías reiniciar la aplicación. Recomendaría probar con JRebel para obtener un cambio rápido de “realizar y guardar los cambios y luego actualizar el navegador y ver los cambios de inmediato”. Puede encontrar el laboratorio práctico JRebel, que muestra cómo usarlo con Tomcat y Eclipse. http://www.javapassion.com/rebels/jrebel_basics/

Me encontré con el mismo problema: intenté todo lo anterior, Eclipse siempre se congeló cuando traté de iniciar el servidor, incluso después de eliminar todas las configuraciones del servidor y crear una nueva con una instancia de tomcat recién descargada. De todos modos, el problema no se resolvió hasta que me mudé a un nuevo espacio de trabajo, reimporté los proyectos y creé un nuevo servidor. Parece un error de Eclipse para mí … Entonces, en caso de que nada funcione, este es el camino a seguir …

Actualmente estoy luchando con el mismo problema, pero nada de lo que se menciona aquí no me ayuda. De todos modos, descubrí que si yo:

  1. detener servidor en eclipse
  2. ejecutar tomcat en otro lugar (en mi caso, la distribución xamp)
  3. dejar de correr actualmente tomcat
  4. comenzar tomcat en eclipse

todo funciona bien, por supuesto hasta que cambie algo en el código y trate de probarlo de nuevo.

Pude resolver esto desactivando la naturaleza maven (clic derecho en project >> maven >> disable maven nature). Luego vuelva a habilitarlo (haga clic derecho en project >> configure >> convert to maven project). Había probado todos los otros trucos y consejos anteriores, pero este fue el que finalmente funcionó.