Comment obtenir l'@ IP d'un client de service web en Java?
Résolu/Fermé
chercheur2017
Messages postés
56
Date d'inscription
mardi 18 avril 2017
Statut
Membre
Dernière intervention
16 décembre 2018
-
7 mai 2017 à 16:45
chercheur2017 Messages postés 56 Date d'inscription mardi 18 avril 2017 Statut Membre Dernière intervention 16 décembre 2018 - 11 mai 2017 à 17:02
chercheur2017 Messages postés 56 Date d'inscription mardi 18 avril 2017 Statut Membre Dernière intervention 16 décembre 2018 - 11 mai 2017 à 17:02
A voir également:
- Comment obtenir l'@ IP d'un client de service web en Java?
- Ethernet n'a pas de configuration ip valide - Guide
- Waptrick java football - Télécharger - Jeux vidéo
- Orange service client - Guide
- Jeux java itel football - Télécharger - Jeux vidéo
- Chaque fichier en ligne sur le web a un chemin d’accès sur un serveur. c’est le cas du fichier du logo présent sur la page de cette ville. quel est le chemin de ce fichier à partir de la racine du site ? - Forum Graphisme
1 réponse
KX
Messages postés
16752
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
31 août 2024
3 019
7 mai 2017 à 18:20
7 mai 2017 à 18:20
Bonjour,
"j'ai créé un service web"
Le code que tu nous montre (avec une méthode main) ce n'est pas un service web, mais une application Java standard, c'est donc normal que tu n'arrives pas à intégrer le code dedans.
Normalement le point d'entrée de tes appels web service c'est une servlet (une AxisServlet dans ton cas ?), c'est à ce niveau que tu peux récupérer l'ensemble des informations de la requête effectuée au serveur.
InetAddress.getLocalHost()c'est faux, ça va te renvoyer l'adresse IP de ton serveur, pas du client.
request.getHeader("X-FORWARDED-FOR");est mieux, même s'il est à noter qu'il peut contenir plusieurs adresses IP, et que d'autres adresses IP peuvent se trouver dans d'autres headers.
"j'ai créé un service web"
Le code que tu nous montre (avec une méthode main) ce n'est pas un service web, mais une application Java standard, c'est donc normal que tu n'arrives pas à intégrer le code dedans.
Normalement le point d'entrée de tes appels web service c'est une servlet (une AxisServlet dans ton cas ?), c'est à ce niveau que tu peux récupérer l'ensemble des informations de la requête effectuée au serveur.
7 mai 2017 à 19:01
On modifie un petit peu la classe SimpleService pour rajouter l'adresse IP :
On compile et on démarre le serveur :
Et on appelle http://localhost:8080/services/SimpleService/helloService?msg=KX
Ce qui donne :
étant l'adresse IPv6 correspondant à localhost
8 mai 2017 à 16:56
Seulement, j'ai eu encore quelque difficulté vu que je ne programme pas trop (j'occupe un poste de chercheur).
Concernant l'exemple que tu m'a envoyé, j'ai commencé par taper la ligne de commande lié à Maven sur la console et ça c'est bien déroulé (succès). par la suite, j'ai écrit la classe SimpleService sur un bloc note pour la tester d'abord. je compile sur la console et j'obtient 8 erreurs que j'ai pu réduire en 5 (après avoir attribué le chemin du fichier servlet.jar à la variable CLASSPATH). les erreurs qui restent sont liées principalement aux 'import' de la ligne 5 et 6 (package does not exist). j'ai cherché mais je n'est pas pu résoudre le problème!!
si tu a une idée sur ça, prière de me tenir au courant et de me décrire plus clairement les étapes à suivre si possible (vu que je ne programme pas trop).
merci pour ton aide et ta compréhension.
8 mai 2017 à 18:41
Ça n'a pas de sens de tester un code serveur sur un programme client, car toute la "magie" vient de ce qui est fourni par le serveur.
Il faut bien comprendre qu'au final le programme qui fonctionnera ce n'est pas le war, mais le serveur Tomcat (ou Jetty, ou autre) mais le war tout seul (ou pire, une classe de ce war tout seul) ne peut pas fonctionner sans le serveur qui s'exécute derrière.
"les erreurs qui restent sont liées principalement aux 'import'"
La première ligne de commande génère un projet d'exemple, la classe SimpleService existe déjà dedans (dans le répertoire src/main ) et ses imports sont configurés dans le pom.xml de manière à ce que le projet puisse compiler et être exécuté tel quel, sans problème. Tu n'as donc rien de plus à faire pour que ça fonctionne. Juste les deux commandes Maven que je t'ai donné.
"après avoir attribué le chemin du fichier servlet.jar à la variable CLASSPATH"
C'est inutile et de manière générale utiliser variable CLASSPATH est une mauvaise pratique, c'est pour cela que Maven gère ses dépendances directement au sein de la configuration de son projet (dans le fichier pom.xml)
Tu peux tester directement comme ceci (en repartant de zéro)
http://localhost:8080/services/SimpleService/helloService?msg=KX
Reste juste à faire les modifications spécifiques pour avoir l'adresse IP.
9 mai 2017 à 15:19
J'ai réessayé l'exemple, et quand je lance la dernière commande 'mvn clean package jetty:run', au début ça commence à s'exécuter, et par la suite le curseur se met à clignoter sans avoir terminé l'exécution et ça ne se débloque pas!!!
9 mai 2017 à 19:10
"le curseur se met à clignoter sans avoir terminé l'exécution"
La dernière log avant le curseur c'est ?
Alors c'est tout à fait normal :-)
Il n'y a pas de fin d'exécution sur un serveur web, il traite les requêtes au fur et à mesure qu'il les reçoit jusqu'à ce qu'on arrête explicitement le serveur.
Donc dès que le serveur est démarré tu peux utiliser le serveur, par exemple :
http://localhost:8080/services/SimpleService/helloService?msg=KX
Dans le projet d'exemple il n'y a pas de logs, mais s'il y en avait, elles apparaîtraient au fur et à mesure car c'est la console du serveur (System.out et System.err) donc tous les messages viendraient s'y afficher.
Après comment arrêter le serveur, au choix :
Pour utiliser , remplacer dans le pom.xml les lignes 64 à 72 par :
Remarque : on pourrait aussi en profiter pour ajouter un plugin Tomcat, mais autant que je sache il n'est plus maintenu, le dernier date de Tomcat 7.
Jetty fait de toute façon exactement le même travail, donc pour une phase de développement ça suffit.
De toute façon que le war soit déployé sur un Tomcat, un Jetty, ou un autre serveur Java, ça ne change pas grand chose tant qu'on ne fait pas de configuration spécifique pour un serveur cible en particulier.