Un mappage de servlet par défaut se limite au caractère /. Dans les serveurs d'applications concurrents, un appel à la méthode javax.servlet.http.HttpServletRequest.getServletPath pour un mappage de servlet par défaut renvoie la valeur de l'URI de la demande moins le chemin de contexte, et un appel à la méthode javax.servlet.http.HttpServletRequest.getPathInfo renvoie la valeur null.
Dans WebSphere Traditional, un appel à getServletPath pour un mappage de servlet par défaut renvoie une chaîne vide et un appel à la méthode getPathInfo renvoie le caractère /.
De même, si vous migrez vers Liberty et utilisez les implémentations de fonctionnalités Servlet 3.0 ou 3.1, un appel à getServletPath pour un mappage de servlet par défaut renverra une chaîne vide et un appel à la méthode getPathInfo renvoie le caractère /.
Par exemple, considérons le code suivant :
Dans les serveurs d'applications concurrents, ce code produit la sortie suivante :
Toutefois, dans WebSphere Traditional et dans Liberty avec Servlet 3.0 ou 3.1, le code produit les résultats suivants :
Si vous migrez vers WebSphere Liberty et utilisez les implémentations Servlet 3.0 ou 3.1, ajoutez l'élément <webContainer servletPathForDefaultMapping="true"/> au fichier de configuration server.xml. L'ajout de cet élément entraîne le comportement des méthodes getServletPath et getPathInfo comme dans les serveurs d'applications concurrents.
Si vous utilisez l'implémentation Servlet 4.0, aucune modification n'est nécessaire. getServletPath
et getPathInfo dans l'implémentation Servlet 4.0 se comportent de la même manière que dans les serveurs d'applications concurrents.
Si vous migrez vers WebSphere Traditional, définissez la propriété com.ibm.ws.webcontainer.EnableDefaultServletRequestPathElements WebContainer sur true.
Si vous définissez cette propriété, les méthodes getServletPath et getPathInfo se comportent comme dans les serveurs d'applications concurrents.
Pour plus d'informations, voir :