Discussion :

[lamoua76]

Bonjour à tous,

Dans le cadre de l'analyse d'un bug, Je recherche un moyen de tracer tout ce qu'envoie tomcat.

Je ne sais pas si ma question est pertinente mais voici mon problème :
Un client contact une URL qui est censée retournée un document WSDL (un web service).
Seulement, parfois, une exception est levée et m'indique qu'au lieu d'un document WSDL, du HTML est retourné suite à un timeout. J'en déduis qu'une erreur type 404/500 est retournée à la place du WSDL.

Seulement entre le client et le serveur, il y plusieurs briques sur lesquelles je n'ai pas la main. Ces briques sont des reverse proxy/apache/nginx "savamment" mis les uns derrières les autres... (bref).

Le serveur de l'appli web utilisée par le client m'est accessible (mais aps le code de l'appli web elle-même) ainsi que le serveur du web service. Il s'agit de deux tomcat distincts.

Ainsi, pour savoir quelle brique retourne le document HTML à la place du WSDL, j'aurais besoin de logger tout ce qu'envoient mes 2 tomcats. J'ai bien vu les Valves pour logger les accès, mais ce n'ai pas suffisant.

Merci d'avance pour vos réponses.
Cordialement.

[hasalex]

Tu peux ajouter des valves pour ça. Tomcat en fournit 2 par défaut : l'AccessLogValve et RequestDumperValve.

L'AccessLogValve peut être utilisée sans problème en production. Elle sort des logs identiques à ceux d'Apache httpd, avec 1 ligne par requête HTTP. Tu sauras par exemple si tu as des réponse 40x ou 50x.

Si tu veux savoir plus précisément ce qui entre et sort, tu devras utiliser la RequestDumperValve, qui écrit les requêtes complètes et les réponses complètes dans les logs. Par contre, le volume des logs n'est pas compatible avec un usage en prod.

[lamoua76]

Ok merci, j'étais bien tombé sur l'access valve, mais je suis visiblement passé à côté de la RequestDumperValve.
Je vais regarder ça de plus prêt !