eclipse/Tomcat: le déploiement ne fonctionne plus (ClassNotFoundException)
J'utilise Eclipse Helios Service Release 1, avec Tomcat 7.0.12 dans Linux Ubuntu Natty Narwhal.
J'ai redoublé de plaisir à déployer mon application Web jusqu'à ce qu'elle cesse de fonctionner sans raison apparente. L'exception suivante est affichée:
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)
- Dans l'onglet Servers, j'ai "Tomcat v7.0 Server sur localhost [Démarré, Synchronisé].
- Mon projet apparaît en tant qu'enfant de Tomcat v7.0 Server
- Dans Propriétés, Chemin de construction Java, Source J'ai le dossier source Project/src
- Dans Propriétés, Ensemble de déploiement Web, j'ai les mappages suivants: / WebContent -> /, / src -> / WEB-INF/classes, / test -> / build/classes
- Mon répertoire src contient un servlet dans obliquid/servlet/Index.Java
- J'ai déjà essayé de cliquer sur Nettoyer le répertoire de travail du module ... et Publier
- J'ai essayé d'arrêter et de démarrer le serveur à partir de l'onglet Serveurs Eclipse
Que dois-je vérifier? Je vous remercie.
UPDATEBien que je travaille maintenant sur le nouveau projet, je suis revenu vérifier l'ancien, et mystérieusement, cela fonctionne maintenant. Je pense que je ne pourrai pas trouver ce qui est arrivé.
Cependant, aujourd'hui, avec le nouveau projet, j'ai eu 404 erreurs sans raison apparente et j'ai découvert qu'un clic droit sur le serveur Tomcat et la sélection de "Nettoyer ..." peuvent être utiles. Peut-être que cela aurait pu aider.
Sélectionner "Nettoyer ..." indique: "Nettoyer supprimera tout état de publication et republiera à partir de zéro. Voulez-vous vraiment nettoyer toutes les ressources publiées?". En sélectionnant oui, j'ai résolu le problème
UPDATE 2 Cela s'est reproduit dans le nouveau projet. 404 erreurs, cette fois, elles ne disparaissent pas.
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)
UPDATE 3 Il s'est avéré que cette fois-ci, je n'avais pas remarqué une exception provoquée par une classe d'écoute au démarrage. Après avoir résolu le problème, cela a fonctionné. Je suppose que je devrais arrêter de travailler à 3 heures du matin.
Alors que sur Tomcat 6 et Eclipse Ganymede, j'ai découvert la chaîne suivante pour fonctionner comme un charme:
1 serveur stop
2 projet -> nettoyer
3 génération de projet (j'avais la construction automatique désactivée)
4 supprimer le serveur
5 supprimer le dossier Serveurs
6 redémarrer Eclipse
7 créer un nouveau serveur, ajouter un projet et démarrer :)
prend du temps mais a travaillé comme un charme. Mon problème était un problème irritant au début de l'auditeur, mais cela semble être quelque chose de similaire: une propriété chez Tomcat. Au fait: je suis aussi un grand fan de Glassfish.
J'ai trouvé que cette procédure est utile:
- Cliquez sur Serveurs onglet et arrêtez le serveur en cours d'utilisation
- Cliquez à nouveau avec le bouton droit sur le serveur et sélectionnez Nettoyer ...
- Cliquez à nouveau avec le bouton droit de la souris et sélectionnez Nettoyer le répertoire de travail Tomcat ...
Espérons que l'exception ClassNotFoundException devrait disparaître maintenant.
Une autre fois, j'ai eu un problème avec une classe lancée au démarrage du serveur, une exception dans une classe d'écoute (ServletContextListener). Lorsqu'un ServletContextListener déclenche une exception au démarrage, le déploiement de l'application est abandonné, d'où les erreurs 404. Dans ce cas, la résolution du problème à l'origine de l'exception a permis à l'application de fonctionner à nouveau.
EDIT: Cette procédure plus courte a fonctionné pour moi la plupart du temps, mais aujourd'hui, elle n'a pas fonctionné et j'ai dû suivre la procédure étendue de Mico. Ma suggestion est, si vous avez un problème similaire, essayez d'abord cette procédure plus courte. Si le problème persiste, essayez avec Mico.
Je vous recommande d'arrêter et de redémarrer le serveur Tomcat. Le déploiement à chaud ne fonctionne pas pour toujours; Certains problèmes vous obligeront à redémarrer après quelques redéploiements.
Je me demande quand je vois le accepté réponds avec +25 est-ce vraiment précis ?
Tout d'abord, si vous souhaitez supprimer le serveur, quel est l'intérêt de le nettoyer? Cela prendra prendra votre temps inutilement et vous ne gagnerez rien d’utile.
Donc, je dirai juste 5, 6, 7 étapes devraient faire la magie
5 supprimer le dossier Serveurs
6 redémarrer Eclipse
7 créer un nouveau serveur, ajouter un projet et démarrer
Cela pourrait être quelque chose que j'ai appris sur con-fess 2011 . Pour moi, cela ressemble à un problème de chargeur de classe.
La théorie derrière:
Java n'utilise pas seulement le type de la classe mais également le chargeur de classes qui l'a chargée pour identifier le type d'une instance. Cela signifie qu'une opération simle pourrait échouer, par ex.
ClassA a1 = new a1; ClassA a2 = SomeOtherClass.giveMeInstanceOfA (); A1 = a2;
Cet exemple échouera si SomeOtherClass utilise un chargeur de classes différent, car Java dira qu'ils ne sont pas identiques.
- L'orateur a également mentionné que certains serveurs utilisent par défaut environ 45 chargeurs de classe différents.
Qu'est-ce que cela signifie en pratique:
Vous déployez votre application Web sur le serveur, tout fonctionne correctement. Le serveur met en cache les classes et tout ce dont il a besoin pour les charger quelque part. Vous effectuez maintenant un déploiement à chaud et le serveur peut charger de nouvelles classes avec un nouveau chargeur de classe (ou différent). C’est le moment où cela commence à devenir dangereux car vous avez désormais deux classes différentes dans la mémoire qui devraient être identiques. Les opérations simples telles que les conversions (ClassA a = (ClassA) new ClassA ()) échouent, les nouvelles méthodes de la classe ne sont pas trouvées (car le serveur utilise une version mise en cache sans cette méthode), ....
C’est à ce moment-là que je redémarre le serveur, nettoie le répertoire de travail (pour supprimer les versions en cache) et commence à penser au déploiement à chaud en tant qu’élément essentiel.
S'il est possible d'essayer Mikkos procédere et que cela résout le problème, cette explication pourrait vous aider à comprendre pourquoi.
Je sais que cela ne résout pas votre problème, mais que je pourrais vous donner des indices sur ce qui aurait pu arriver.
J'ai acquis de nouvelles expériences en programmation et je ne suis plus affamé par la combinaison Eclipse + Tomcat. Plusieurs manières peuvent vous aider à ne plus avoir besoin de cette combinaison:
Tout d'abord, ne les utilisez pas ensemble!
Vous pouvez utiliser d'autres IDE disponibles, par exemple IntellijIdea (qui n’est pas gratuit, mais vaut la peine d’investir) a une propriété qui permet de déboguer un code Java, de modifier le code à la volée, de compiler les fichiers Java un par un, puis de vous suggérer de le faire mis à jour sur le serveur. Pas de redémarrage nécessaire presque jamais (bien sûr, il est parfois perdu, mais cela fonctionne principalement).
Utilisez un serveur Tomcat autonome, et non celui d'Eclipse/votre IDE. Cette première astuce ne fonctionne que lorsque vous déboguez un serveur externe, rien dans IDE. Voici le deuxième conseil: si vous ne modifiez que le contenu jsp ou html, ces fichiers peuvent être copiés au bon endroit dans le dossier webapp de Tomcat manuellement avec la commande unix cp ou windows copy et si vous développez des fichiers dans le même temps , vous pouvez copier le contenu du dossier (par exemple, myFolder/* .jsp) autant de fois que vous le souhaitez et aucun redémarrage n’est nécessaire. Les modifications sont visibles lorsque vous touchez ou modifiez et enregistrez le fichier web.xml dans le dossier webapps, puis que vous actualisez la page visible dans le navigateur. Une actualisation difficile avec CTRL + F5 est probablement la meilleure solution.
Merci à @Verdan pour son commentaire, sinon je ne serais pas revenu pour répondre à nouveau.
Je suis actuellement aux prises avec le même problème, mais rien de mentionné ici ne m'aide. Quoi qu'il en soit, j'ai découvert que si je:
- arrêter le serveur dans Eclipse
- lancer Tomcat ailleurs (dans mon cas, la distribution xamp)
- arrêter de courir actuellement Tomcat
- démarrer Tomcat dans Eclipse
tout fonctionne correctement, bien sûr, jusqu'à ce que je modifie quelque chose dans le code et que je tente de le tester à nouveau.
J'ai pu résoudre ce problème en désactivant la nature maven (clic droit sur le projet >> maven >> désactiver la nature maven). Puis réactivez-le (clic droit sur projet >> configurer >> convertir en projet maven). J'avais essayé tous les autres trucs et astuces ci-dessus, mais c'est celui qui a finalement fonctionné.
En parlant de déploiement à chaud de Tomcat, vous rencontreriez en effet divers problèmes, le moindre étant une fuite de mémoire, ce qui vous obligerait à redémarrer l'application. Je recommanderais d'essayer JRebel pour un redressement rapide de "faire et enregistrer toutes les modifications, puis actualiser le navigateur et voir les modifications immédiatement". Vous pouvez trouver le laboratoire pratique JRebel, qui montre comment l'utiliser avec Tomcat et Eclipse. http://www.javapassion.com/rebels/jrebel_basics/
Je rencontrais le même problème - j'ai essayé tout ce qui précède, Eclipse était toujours bloqué lorsque j’essayais de démarrer le serveur, même après avoir supprimé toutes les configurations de serveur et en avoir créé une nouvelle avec une instance récemment téléchargée de Tomcat. Quoi qu’il en soit, le problème n’a pas été résolu tant que je n’ai pas déménagé dans un nouvel espace de travail, réimporté les projets et créé un nouveau serveur. Cela me semble un bogue Eclipse ... Donc, si rien d’autre ne fonctionne, c’est la voie à suivre ...