Migration des composants d'applications Web à partir de WebSphere Application Server version 5.x
Il n'est généralement pas nécessaire de faire migrer les applications web déployées dans des versions antérieures de WebSphere Application Server. Les versions 2.2 et ultérieures de la spécification Java™ Servlet et les versions 1.2 et 1.4 des spécifications JavaServer Pages (JSP) sont toujours prises en charge, sauf si leur comportement a été modifié dans les spécifications Servlet 3.1 ou JSP 2.3. Ces modifications sont généralement disponibles, de manière plus détaillée, dans leur spécification correspondante.
Pourquoi et quand exécuter cette tâche
La migration de servlets peut poser problème dans les situations suivantes :
- implémente un servlet WebSphere Application Server interne pour contourner une restriction de chemin d'application unique de WebSphere Application Server version 4.x
- étend un PageListServlet qui repose sur des informations de configuration dans le fichier de configuration XML du servlet
- appelle la méthode response.sendRedirect pour un servlet utilisant la fonction encodeRedirectURL ou démarrant dans une racine non contextuelle
- dépend de la définition d'un en-tête Content-Type par défaut ou du comportement d'un appel setContentType après l'émission d'un appel getWriter. Ce comportement est défini
par le niveau de version WebSphere
Application Server utilisant la propriété personnalisée de conteneur com.ibm.ws.webcontainer.contenttypecompatibility avec une valeur V4, V5, V6 ou V7. Le comportement de chaque version est décrit dans le tableau 1.
Tableau 1. Propriétés personnalisées du conteneur Web.. Décrit le comportement de chaque version. Version 4 Version 5 Version 6 Version 7 Content-Type par défaut text/html text/html; charset=<codage_par_défaut> Aucune Aucune Ajoute Charset à getWriter si la propriété n'existe pas pour Content-Type Exemple : response.setCharacterEncoding("UTF-8"); response.setContentType("text/xml"); response.getWriter();
text/html text/html text/xml; charset=UTF-8 text/xml; charset=UTF-8 Supprimez le jeu de caractères de la propriété Content-Type si la propriété setContentType est appelée après getWriter comportant une partie ";charset=" Exemple : setContentType("text/html;charset=ISO-8859-7"); getWriter(); setContentType("text/xml;charset=UTF-8");
text/html text/html text/html text/xml; charset=ISO-8859-7
La migration JSP peut poser des problèmes si votre
application référence des classes d'implémentation de pages JSP dans des packages sans nom ou
si vous installez dans la version 5.x des fichiers EAR de la version 4.x de WebSphere
Application Server (déployés dans la version 4.x à l'aide de l'option de compilation préalable des fichiers JSP). Vous devez recompiler toutes les pages JSP lors de la migration depuis la version 5.x de WebSphere
Application Server.
La migration JSP peut poser des problèmes si votre
application référence des classes d'implémentation de pages JSP dans des packages sans nom ou
si vous installez dans la version 5.x des fichiers EAR de la version 4.0.1 de WebSphere
Application Server (déployés dans la version 4.0.1 à l'aide de l'option de compilation préalable des fichiers JSP). Vous devez recompiler toutes les pages JSP lors de la migration depuis la version 5.x de WebSphere
Application Server.

Toutefois, un module Java EE 5 ou version ultérieure peut exister dans une application qui inclut des fichiers antérieurs à Java EE 5 et utilise l'extension de nom de fichier .xmi.
Les fichiers ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi et ibm-portlet-ext.xmi continuent d'utiliser les extensions de fichier .xmi.
sptcfgPour faire migrer votre application web, procédez aux opérations ci-dessous.