Moniteur http/soap port already in use

Bonjour,

J'ai installé la solution NetBeans5.5/Glassfish_v1 et les extensions WSIT pour chacun des composants. Mon serveur http écoute sur le port 4040. Jusque là tout va bien.

J'ai récupérer wsMonitor pour capturer les échanges protocolaires.
https://wsmonitor.dev.java.net/

Ce moniteur http/soap fonctionne sur la base d'un fichier config.xml :

Code:

---

1 2 3 4 5 6 7 8 9

<monitor xmlns="http://java.sun.com/xml/ns/jax-ws/ri/config/monitor" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="config.xsd"> <connection name="4444--> localhost:8080" description="4444->8080" listenPort="4444" targetHost="localhost" targetPort="8080"/>

---

Le hic, c'est lorsque que je paramètre l'écoute sur le port 4444, il me signale et c'est logique que le port est en cours d'ultilisation :

Citation:

---

{http://java.sun.com/xml/ns/jax-ws/ri/config/monitor}connection
Line number = 38
Column number = 28
System Id = null
Public Id = null
Location Uri= null
CharacterOffset = 1382

java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at java.net.ServerSocket.<init>(ServerSocket.java:97)
at com.sun.tools.ws.wsmonitor.Listener.run(Listener.java:45)

---

Quelque chose m'échappe..

Merci d'avance

GlassFish v2 + NetBeans 5.5.1 me paraissent plus adaptés (WSIT est intégré dans GFv2). Pour la bonne combinaison (en attendant la version finale): http://weblogs.java.net/blog/arungup...version_o.html

Pour le port d'écoute, GlassFish en utilise plusieurs (indiqués au lancement du serveur). Il est possible que le port 4444 soit déjà occupé. Il suffit de changer la config de wsmonitor...

bonjour alexismp et merci pour ta réponse,

En effet 4444 est le port d'ecoute http glassfish (le port 8080 est occupé sur ma machine).

Code:

---

1 2 3 4 5

<connection name="4444--> localhost:8080" description="4444->8080" listenPort="4444" targetHost="localhost" targetPort="8080"/>

---

l'attribut listenPort c'est bien le port que surveille le wsmonitor??

[client] ----> [wsmonitor:listenPort] -----> [GlassFish:targetPort].
Les noms ne sont peut-être pas heureux...

J'ai fixé mon config.xml comme ceci :

Code:

---

1 2 3 4 5 6

<connection name="4444--> localhost:8080" description="4444->8080" listenPort="3652" targetHost="localhost" targetPort="4444"/>

---

LOrs du lancement le message suivant est produit :

Code:

---

Waiting for connections at 3652

---

Lorsque je lance un client ws :

Code:

---

http://localhost:4444/MonAppli

---

Le moniteur reste désespérement vide

Y a t'il quelque chose à configurer coté déploiement du ws..?

Le tunnel écoute sur le port 3652 et redirige vers 4444.

Bonjour,

Je reviens sur ce post, ca tombe certainement sous le sens mais je ne m'en sort pas.. comment dois je configurer pour écouter des requêtes http à cette adresse :

http://localhost:4444/clientWS

si je positionne 4444 comme port pour la balise listenPort dans config.xml, au moment du lancement de wsmonitor j'ai un message comme quoi le port est utilisé (en effet mon serveur glassfish répond à ce port là) :roll: :(

Par contre si j'arrete le serveur glassfish, je peux lancer avec cette config.. mais évidemment pas de trace

Avec un tunnel, au lieu de s'adresser au serveur, le client s'adresse au au tunnel qui redirige ensuite les requêtes vers le serveur. Le tunnel a donc un port d'écoute (celui auquel doit s'adresser le client) et renvoi les requêtes sur une autre port du serveur.

Idéalement, tu gardes 8080 comme port d'écoute pour GlassFish. 4444 est le port d'écoute (listenPort) du tunnel (chacun le sien, pas de problème au démarrage). Le client doit parler au 4444.

Si tu le souhaites, il y a peut-être plus simple avec les options de log de glassfish:

Code:

---

1 2	-Dcom.sun.xml.ws.runtime.client=true -Dcom.sun.xml.ws.runtime.server=true

---

à placer dans le domain.xml

Il s'agissait bien d'un problème de compréhension de ma part, on substitue donc le port d'écoute du serveur par le port du tunnel.. maintenant cela fonctionne.

Merci Alexismp pour ton aide précieuse.