Remarques relatives à Java Servlet

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 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.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_consid
Nom du fichier : cweb_consid.html