Sur mon PC, tout roule.
Sur un serveur de prod, tomcat me rend une erreur 404 avec le message d'erreur suivant :
La ressource demandée (/interface/lds_records.jsp;jsessionid=4E1B8A526DD5EFFC9DB980F3E29EFD0E) n'est pas disponible.
Je soupçonne le bout de code suivant d'être responsable de ça (plus particulièrement le "encodeURL" :

 
Quelqu'un a une explication au fait que le changement de serveur pose ce pb ?

Petit complément : ce message sort quand la session viend d'être construite. Au 2e appel par un explorateur web (actualisation de la page), l'erreur ne se produit plus.

c'est n'importe quoi ton truc là ...
pkoi tu fais un response.encodeUrl() avant de fair un dispatch ?????
 
tu crois faire quoi en faisant ca ?

Avec ça, je croyais inclure, si besoin est, l'id de session dans la requète (si les cookies ne sont pas acceptés par le client par exemple). Je me plante apparement. Je dois l'utiliser quand alors cet encodeURL ?

un dispatch c'est une redirection serveur : tu passes la requête d'une servlet à une autre. Ca repasse pas par le client => ca ne sert à rien de voiloir ajouté l'id de session. Si dans la première servlet, tu as la session, tu l'auras aussi dans la 2e, et inversement.

C'est au pralable (dans les pages HTML générée) que tu dois avoir ajouté l'id de session :  
 
<a href="<%= reponse.encodeURL("index.html" )%>">coucou</a>

 
Je sais que c'est une redirection server. J'avais pas vu les choses comme ça. Merci.
D'ailleurs, au passage, je sais pas si c'est super clean : desfois lors d'une redirection serveur, j'en profite pour ajouter des paramètres (en ajoutant des ?monparam1=maval1&mmoparam2=maval2). je doute que ça soit bien propre, mais sous Tomcat ça fonctionne.

bha, je vois pas d'inconvénient à utiliser ca ... et c'est pas spécifique Tomcat : ca fait parti de la norme servlet2.3 => tous les moteurs de servlet doivent gérer ca.

Ha, ben c'est cool ça. J'en doutait, ça me parraissait "bidouille". Dans le cas contraire, je comprend pas pourquoi la classe HttpServletRequest n'a pas de méthode "setParameter"

parce que ca représente la requête sous forme d'objet et que cette requête t'as été envoyé par l'utilisateur et n'est donc pas modifiable. le coup du dispatch avec des paramêtres en plus ne modifie pas la requête mais ca l'encapsule dans un wrapper (HttpServletRequestWrapper) qui se comportera "comme si" la requête contenait les paramètres supplémentaires.

ok. Merci beaucoup pour la petite expliquation.