WebSphere Application Server TraditionalVersion 9.0 prend en charge la spécification Servlet 3.1.
En savoir plus sur las fonctions et les changements de comportement pour Servlet 3.1.

Nouvelle fonction:
Le produit prend en charge Servlet 3.1, qui inclut des fonctions
et des changements de comportement introduits dans la spécification
Servlet 3.0. Pour plus d'informations, voir les fonctions Servlet 3.1. Si vous migrez depuis Servlet 2.5 ou une version antérieure vers Servlet 3.1, prenez également
en compte les changements de comportement pour Servlet 3.0.newfeat
Java™ Servlet 3.1 offre
une grande variété de fonctions puissantes. Quelques-unes de ces fonctions ne sont pas entièrement documentées
dans la spécification Servlet 3.0, ou bien elles impliquent de faire
certains compromis.
Lisez les conseils qui suivent pour tirer le meilleur parti
des nouvelles fonctions.
Annotations
Les annotations Java
Servlet 3.0 sont récupérées par les modules Web Servlet 2.5, ce qui peut conduire à exposer un servlet
sur le Web. Soyez prudent quand vous mettez à niveau les logiciels prérequis d'une ancienne application, car les
nouvelles annotations sont traitées et le fichier JAR des logiciels prérequis peut contenir des annotations que vous
ne souhaitez peut-être pas appliquer.
Téléchargement (upload) de fichiers
Le téléchargement de fichiers (formulaires multiparties)
est une nouveauté dans la spécification Servlet 3.0. L'emplacement par défaut pour l'écriture
des fichiers est le même que l'emplacement désigné par
l'attribut javax.servlet.context.tempdir. Par exemple,
C:\opt\WAS\profiles\node1\temp\node1\server1\fragmentTest\fragmentTest24.war est produit pour une configuration avec les attributs suivants :
- profile home=C:\opt\WAS\profiles\noeud1
- server name=server1
- enterprise application name=fragmentTest
- web module name=fragmentTest24.war
Les chemins relatifs sont
également définis par rapport à cet emplacement par défaut.
Vous pouvez changer
la valeur de l'attribut javax.servlet.context.tempdir de manière à la rendre relative
à un autre répertoire. Pour cela, utilisez la propriété
système com.ibm.websphere.servlet.temp.dir.
Cette propriété système affecte toutes
les applications à l'échelle du serveur. Par exemple, si vous affectez à com.ibm.websphere.servlet.temp.dir la valeur /foo, le répertoire temporaire de l'application est /foo/node1/server1/fragmentTest/fragmentTest24.war. Si vous voulez changer la valeur au niveau de l'application, utilisez l'attribut scratchdir
JavaServer Pages (JSP). Reportez-vous à la rubrique sur les paramètre de configuration du moteur JSP pour plus de détails
sur l'attribut scratchdir.
Configuration programmatique ou dynamique de session HTTP
La configuration programmatique
de session HTTP est une nouvelle fonction qui permet à une application de modifier la configuration de session utilisée,
soit au moyen du descripteur
web.xml, soit par des appels aux méthodes
de l'API. Une fois l'application démarrée, il n'est pas possible de changer le nom de cookie modifié dynamiquement.
Pour des raisons de sécurité, les administrateurs peuvent désactiver
cette fonction pour des cookies particuliers susceptibles d'être
partagés par plusieurs applications. Généralement, il n'y a pas de risque à modifier la configuration
d'un cookie, mais à condition qu'il ait un nom et un chemin uniques, afin que l'application soit la
seule à y accéder. A l'aide de la fonction de gestion des sessions, vous pouvez
changer le chemin par défaut des cookies afin que chaque application utilise à la
place sa propre racine de contexte.
Important : Changer le chemin des cookies peut affecter
le fonctionnement de certaines extensions IBM, telles que le partage de session ou la
méthode IBMSessionExt.invalidateAll, qui sont tributaires de l'utilisation d'un seul et même cookie pour
plusieurs applications.
Les cookies dynamiques ont les conséquences suivantes
sur les services intermédiaires :
- Un proxy d'entreprise extrait automatiquement un cookie dynamique lorsqu'une application
démarre et qu'elle utilise le cookie pour l'affinité de session.
- Un proxy de zone démilitarisée en mode de sécurité faible ou moyen extrait également automatiquement un cookie
dynamique lors du démarrage d'une application. Pour un proxy de zone démilitarisée en mode de sécurité élevée, l'extraction
n'est pas automatique. L'application doit être en cours d'exécution avant que les informations de routage cible
ne soient exportées.
- Un plug-in de serveur Web ne peut pas obtenir le cookie dynamique automatiquement
car il ne communique pas avec les serveurs d'applications pour les informations
de configuration. Vous devez démarrer l'application, générer la configuration
de plug-in, propager la configuration au plug-in puis recharger la configuration pour le plug-in
afin d'obtenir le cookie.
- Dans l'environnement cluster, le nom du cookie dynamique généré sur
chaque serveur doit être le même. Dans le cas contraire, les services intermédiaires
peuvent ne pas être en mesure d'acheminer les demandes.