3 votes

eclipse vs déploiement tomcat - la guerre exportée (partiellement) échoue alors que le projet fonctionne dans eclipse

J'ai une application web dans eclipse juno - lorsque je tape sur la touche Exécution sur le serveur fonctionne bien - que ce soit dans le navigateur d'eclipse (je suis sous Windows) ou dans FF.

Clic droit > guerre des exportations > Je dépose ce fichier dans $CATALINA_HOME/webapps > tout fonctionne bien (il a été décompressé sans problème). SAUF

  • mes balises personnalisées - j'avais un WEB-INF\functions.tld qui n'est apparemment pas lu. La seule différence entre le fichier généré automatiquement par eclipse server.xml (en Servers ) et le projet Tomcat par défaut server.xml était la ligne :

    <Context docBase="ted2012" path="/ted2012" 
    reloadable="true"source="org.eclipse.jst.jee.server:ted2012"/>

source étant un attribut spécifique de la VDP.
J'ai réussi à résoudre ce problème - voir mon réponse

  • Tomcat n'arrive pas à faire passer l'URL correctement - voir les images dans mon site web. réponse .

Questions :

  1. (Non résolu) Pourquoi Tomcat ne décode pas correctement l'Url ? alors qu'eclipse le fait ? Où se situe l'échec ? Voir ma page spécifique question pour ce pour des détails complets sur la pile d'appels et où exactement tomcat échoue
  2. Pourquoi tomcat n'a pas vu le tld en premier lieu alors qu'eclipse l'a vu ? Pourquoi ai-je dû modifier le fichier web.xml ? (contournement dans ma réponse, devrait être une autre question)

Le code est dans github - dans le fichier INSTRUCTIONS.txt il y a des instructions détaillées pour mettre en place le projet et reproduire le bug décrit dans ma réponse ci-dessous.

Tomcat 7.0.32, eclipse 4.2, java 1.7.9

5voto

Esailija Points 74052

Pour décoder correctement les URIs, vous avez besoin de l'attribut connecteur URIEncoding dans Tomcat :

<connector ... URIEncoding="UTF-8" ... />

Voir ma diatribe https://stackoverflow.com/a/15587140/995876

Il n'est donc pas fourni avec le code normal, vous devez le faire dans la configuration du serveur d'applications séparément ou utiliser un serveur d'applications qui utilise UTF-8 par défaut. Il n'y a malheureusement aucun moyen d'y remédier à partir du code.

Laissez tomber le decodeRequest et ne jamais utiliser new String/getBytes sans argument explicite de codage.


Alternatif.

Si vous ne pouvez pas modifier la configuration du connecteur du serveur, vous pouvez corriger votre code en fournissant explicitement l'encodage à l'adresse suivante new String :

public static String decodeRequest(String parameter) {
     return new String(parameter.getBytes("iso-8859-1"), "UTF-8");
}

1voto

Mr_and_Mrs_D Points 4569

Une chose qui a aidé a été d'ajouter à la web-xml :

<jsp-config>
    <taglib>
        <taglib-uri>
            functions
        </taglib-uri>
        <taglib-location>
            functions.tld
        </taglib-location>
    </taglib>
</jsp-config>

Maintenant tomcat (7.0.30) voit mon taglib qui est utilisé pour encoder les URIs.


Chose étrange : lorsque j'imprime le nom d'utilisateur avec system out, j'obtiens ? ??? dans la console de tomcat au lieu des hiéroglyphes. Peut-être cela indique-t-il le problème ? Dans mon contrôleur, j'ai :

final String username = Helpers.decodeRequest(request
                .getParameter("user"));
System.out.println("ProfileController.doGet() user name DECODED : "
                                + username);

où :

private static final String CHARSET_FOR_URL_ENCODING = "UTF-8";

public static String decodeRequest(String parameter)
        throws UnsupportedEncodingException {
    System.out.println(Charset.defaultCharset()); // EDIT: suggested by @Esailija
    if (parameter == null)
        return null;
    System.out.println("decode - request.getBytes(\"iso-8859-1\"):"
            + new String(parameter.getBytes("iso-8859-1")));
    System.out.println("decode - request.getBytes(\"iso-8859-1\") BYTES:"
            + parameter.getBytes("iso-8859-1"));
    for (byte iterable_element : parameter.getBytes("iso-8859-1")) {
        System.out.println(iterable_element);
    }
    System.out.println("decode - request.getBytes(\"UTF-8\"):"
            + new String(parameter.getBytes(CHARSET_FOR_URL_ENCODING))); // UTF-8
    return URLDecoder.decode(new String(parameter.getBytes("iso-8859-1")),
            CHARSET_FOR_URL_ENCODING);
}

Donc tomcat :

windows-1252 // EDIT: suggested by @Esailija
decode - request.getBytes("iso-8859-1"):?
decode - request.getBytes("iso-8859-1") BYTES:[B@d171825
-50
-75
-50
-69
-50
-69
-50
-73
-50
-67
-50
-79
-49
-127
-50
-79
decode - request.getBytes("UTF-8"):ÄÄÄÄÄÄ??Ä
ProfileController.doGet() user name DECODED : ?
???????? // user Dao System.out.println("");
com.mysql.jdbc.JDBC4PreparedStatement@67322bd9: SELECT * FROM users WHERE username='?'
ProfileController.doGet() user : null

Eclipse :

UTF-8 // EDIT: suggested by @Esailija
decode - request.getBytes("iso-8859-1"):
decode - request.getBytes("iso-8859-1") BYTES:[B@44c353ae
-50
-75
-50
-69
-50
-69
-50
-73
-50
-67
-50
-79
-49
-127
-50
-79
decode - request.getBytes("UTF-8"):Ï
ProfileController.doGet() user name DECODED : 
 // user Dao System.out.println("");
com.mysql.jdbc.JDBC4PreparedStatement@73aae7c6: SELECT * FROM users WHERE username=''
ProfileController.doGet() user : com.ted.domain.User@4b22015d

EDIT : si je change l'encodage d'eclipse dans prefs > workspace > text file encoding et que je mets le défaut (Cp1252)

windows-1252
decode - request.getBytes("iso-8859-1"):
decode - request.getBytes("iso-8859-1") BYTES:[B@5ef1946a
-50
// same bytes ....
decode - request.getBytes("UTF-8"):Ã?
ProfileController.doGet() user name DECODED : 
Ï?
com.mysql.jdbc.JDBC4PreparedStatement@4646ebd8: SELECT * FROM users WHERE username=''
ProfileController.doGet() user : null

et Eclipse échoue également


NB : Tomcat affiche l'adresse correcte dans la barre d'adresse.

enter image description here

Eclipse est bien :

enter image description here

Remarquez que Firefox décode automatiquement l'URL (à mon grand étonnement).

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X