Le servlet Java ne sera pas compilé - impossible de trouver javax.servlet

J'ai de gros problèmes pour compiler des servlets java. Autant que je sache, ive a fait tout ce que je devais faire, ive installé correctement tomcat 7 et tomcat fonctionne. Si je comprends bien, j'ai besoin d'ajouter le paquet servlet.jar à mon chemin d'accès aux classes. Il ne semble pas y avoir de servlet.jar sur mon système, mais d'après ce que je peux comprendre des documents tomcat, il s'agit maintenant de servlet-api.jar.

J'ai fait cela en éditant le chemin de classe dans /etc/environment :

PATH = "/ usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/jeux" CLASSPATH = "/ usr/share/tomcat7/lib/servlet-api.jar"

Malheureusement, toujours pas de chance, je ne peux pas compiler de servlets java et je reçois toujours des avertissements concernant les symboles manquants pour javax.servlets .

J'utilise Ubuntu 11.10 x64. Des idées?

1

3 Réponses

J'ai fait cela en modifiant le chemin de classe dans /etc/environment :

     

PATH = "/ usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" CLASSPATH = " /usr/share/tomcat7/lib/servlet-api.jar "

Cela semble bien. Le PATH est sans importance pour le problème particulier. Java ne l’a jamais utilisé. Il est uniquement utilisé par la plateforme du système d'exploitation pour rechercher des exécutables. Le CLASSPATH est similaire, mais utilisé uniquement par Java pour rechercher les classes devant être utilisées lors de la compilation et/ou de l'exécution.

Votre problème est probablement dû au fait que vous avez utilisé l'argument -cp ou -classpath de la commande javac . Dans ce cas, la variable d'environnement CLASSPATH sera ignorée (ceci s'applique également à la commande java , même si -jar l'argument est utilisé).

You need to specify the classpath by only either the CLASSPATH environment variable or the -cp or -classpath argument. The general recommendation is to forget about the CLASSPATH environment variable at all as that's considered a poor practice whenever you want to do a bit more than just "Hello World". You can specify multiple paths in the -cp or -classpath argument using :.

$ cd /path/to/package/root/of/your/servlet/code
$ javac -cp .:/path/to/servlet-api.jar com/example/YourServlet.java

Si vous en avez assez de répéter cette opération à chaque fois, il vous suffit de l'insérer dans un script .sh ou d'utiliser un outil de construction tel que Ant, qui permet la configuration à l'aide d'un fichier XML, ou tout simplement un IDE comme Eclipse. Netbeans ou IntelliJ qui le fera tout automatiquement lorsque vous enregistrez le fichier source.

3
ajouté

Vous ne devriez pas avoir de variable d'environnement CLASSPATH.

Une meilleure façon de le faire consiste à utiliser l'argument -classpath pour javac.exe lors de la compilation et java.exe lors de l'exécution. Ajoutez le servlet-api.jar de Tomcat de cette façon.

Une autre suggestion est d'apprendre Ant. C'est un outil de construction basé sur xml et basé sur Java. C'est plus facile à apprendre et à utiliser que Maven. Je commencerais par ça.

2
ajouté

javax.servlets is defined in servlet-api.jar so your issue must be with your config somehow. What are you using to compile? Are you issuing javac commands directly or using a build tool like maven, or ant, or event eclipse? I would recommend maven because it handles dependencies for you with a single configuration file. Really easy to pick up too.

Dans maven, vous devez commencer par installer/configurer maven et démarrer votre projet avec une structure de fichier définie (simplifiée mais suffisante):

/src/main/java - The root of your java files
/src/main/webapp - The root of your webapp
/pom.xml - Maven configuration file

Ainsi, une liste de fichiers complète pour un servlet peut être:

/src/main/java/com/mycompany/myapp/MyServlet.java
/src/main/webapp/WEB-INF/web.xml
/src/main/webapp/index.jsp
/pom.xml

Les 3 premières lignes (autres que la structure du fichier racine) sont identiques à celles de n'importe quelle application Web. La dernière est votre fichier de configuration qui ressemble à ceci:


  4.0.0
  com.mycompany
  myapp
  0.0.1-SNAPSHOT
  war

  
    
      javax.servlet
      servlet-api
      2.5
      jar
      provided
    
  

La partie importante ici est que la dépendance sur servlet-api est gérée par maven, il n’est donc pas nécessaire de la télécharger, ni de configurer des chemins de classes ou quoi que ce soit. Une fois que vous avez défini cette structure de fichier et modifié votre pom, il vous suffit de naviguer dans une console jusqu’à la racine et de taper package mvn . Cela téléchargera vos dépendances, compilera votre code et conditionnera votre guerre. Il y a BEAUCOUP plus que maven offre avec des modifications très minimes. En revanche, ant aurait besoin de ceci:

à ajouter

2
ajouté
"Maven" et "facile" ne font pas partie de la même phrase.
ajouté l'auteur duffymo, source
Je n'ai pas maîtrisé la convention. Peut-être y a-t-il encore de l'espoir, mais je trouve Ant beaucoup plus facile. Je suis un utilisateur de Spring, donc la plupart de mes dépendances sont facilement accessibles. Maven me donne plus de maux de tête qu'il ne guérit.
ajouté l'auteur duffymo, source
Je connais la différence entre Spring et Maven. Ce que je veux dire, c'est que lorsque je télécharge Spring, tous ses fichiers JAR dépendants ont la version correcte. Pourquoi ai-je besoin de Maven?
ajouté l'auteur duffymo, source
Je peux télécharger une fois et tout est prêt. Il me semble plus facile de télécharger une version de Spring plutôt que de supporter Maven à chaque opération.
ajouté l'auteur duffymo, source
Mais Spring est livré avec 99% des dépendances dont j'ai besoin. Ça me trie plutôt bien. C'est comme son propre référentiel Maven.
ajouté l'auteur duffymo, source
Je les veux peut-être un jour, et ils ne font pas de mal assis sur mon disque dur. Je cherche ce que je veux et laisse le reste derrière. Encore plus facile que Maven.
ajouté l'auteur duffymo, source
@duffymo C'est facile quand il s'agit de cas d'utilisation simples, tels que les applications vanilla, les dépôts par défaut, aucun rapport, etc. Passé cela, oui, cela devient parfois très pénible.
ajouté l'auteur Dave Newton, source
@duffymo Tout ne vient pas avec ses propres dépendances, et il n'est pas toujours évident de déterminer quelles dépendances spécifiques sont réellement requises. OMI, il est préférable de laisser quelque chose d'autre gérer la gestion de dépendance transitive dans la plupart des cas.
ajouté l'auteur Dave Newton, source
@ Duffymo, je les ai beaucoup utilisées. Je trouve que Maven est beaucoup plus simple. Convention sur la configuration. Une fois la convention très simple obtenue, vous en recevez beaucoup gratuitement. Plus important encore, la gestion de la dépendance qui est particulièrement utile dans cette situation (ce que vous pouvez faire si vous incluez du lierre qui n’est pas très facile à comprendre).
ajouté l'auteur Lucas, source
@duffymo, je suis totalement un gars de printemps, mais Spring fait l'injection de dépendance (le matériel d'exécution), maven gère la dépendance (s'assure que tous les fichiers nécessaires à la compilation/test/exécution sont disponibles dans le chemin d'accès aux classes). Pour le plaisir, je vais essayer d'ajouter quelques exemples rapides ici ...
ajouté l'auteur Lucas, source
@ Duffymo, Ah, je vois. Cela fait si longtemps que je n'ai téléchargé rien, donc je suppose que c'est pour ça que je dirais que vous avez besoin de maven. Pas besoin de télécharger. Et changer de version est aussi simple que de changer un numéro dans le pom (à ce moment-là, toutes les dépendances seront également mises à jour). En outre, cela garantirait que les autres packages ayant des dépendances n'entrent pas en conflit avec les dépendances introduites par le printemps. La gestion de la dépendance Maven (ou même Ivy si vous voulez y aller) a été de véritables épargnants, selon mon expérience.
ajouté l'auteur Lucas, source
@duffymo, cela impliquerait également qu'il comporte beaucoup de choses dont vous n'avez pas besoin (sauf si vous utilisez tout dans chaque projet).
ajouté l'auteur Lucas, source