Accessibilité

Notes d'accompagnement de JRun

Programme de mise à jour vers la version 6 de JRun 4

Pour Windows®, UNIX™, Linux™ et MacOSX™

Notes de publication

Dernière mise à jour : 29 juillet 2005

Les notes de publication ci-dessous décrivent les problèmes résolus dans la version 6 de Macromedia JRun 4, et contiennent les informations suivantes :

Installation

Le programme de mise à jour vers la version 6 de JRun 4 met à jour toute installation de JRun 4 existante, avec ou sans les Service Packs et y compris les versions antérieures aux programmes de mise à jour.

Avant d’exécuter le programme de mise à jour vers la version 6 de JRun 4, prenez les précautions suivantes :

  1. Vérifiez que le JDK par défaut installé sur l’ordinateur est la version 1.3.1 ou ultérieure (nécessaire au programme d’installation).
  2. Arrêtez tous les services JRun 4. L’installation peut échouer si certains processus JRun ne sont pas arrêtés. Pour déterminer si des services JRun sont encore en cours d’exécution :
    • Sous UNIX et Linux, vérifiez les processus à l’aide de la commande ps -ef ou d’une commande similaire. Arrêtez les éventuels processus JRun encore en cours d’exécution.
    • Sous Windows, appuyez sur la combinaison de touches Control + Alt + Suppr, et sélectionnez le Gestionnaire des tâches.
    • Dans l’onglet Processus, arrêtez les éventuels processus JRun encore en cours d’exécution. Si des serveurs JRun sont installés sous forme de services Windows, arrêtez-les dans l’élément Services du Panneau de configuration.
  3. Arrêtez tous les serveurs Web connectés à JRun. Si vous utilisez IIS comme serveur Web pour JRun, arrêtez le service World Wide Web Publishing dans l’élément Services du Panneau de configuration.
  4. Notez l’emplacement du répertoire racine de votre installation actuelle de JRun 4 (par exemple, c:\jrun4).
  5. Sous Windows 2000, Window XP et Windows 2003, arrêtez le service Windows Management Instrumentation afin d’éviter de verrouiller certaines DLL que le programme de mise à jour doit remplacer, dans {jrun.home}/bin.
  6. Sous Windows XP et Windows 2003, si JRun est désinstallé avant l’exécution du programme de mise à jour, il est nécessaire de supprimer manuellement la clé de registre suivante, faute de quoi toute installation complète et toute mise à jour échoueront :
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\955648EA1E7DC4D4FA99677EE7413103]"ProductName"="Macromedia JRun 4"

Pour plus d'informations sur la modification de clés dans le registre de Windows, consultez la documentation de votre système d'exploitation.

Pour effectuer la mise à jour de votre installation de JRun 4 à l’aide du programme de mise à jour vers la version 6 :

  1. Téléchargez et exécutez le fichier EXE ou BIN destiné à votre système d'exploitation.
  2. Suivez jusqu’au bout les instructions de l’Assistant d’installation.
  3. Supprimez le contenu du répertoire SERVER-INF/temp de chaque serveur JRun.
  4. Lorsque l’installation est terminée, redémarrez les services JRun et, si nécessaire, votre serveur Web.
  5. Certaines versions de Linux peuvent nécessiter une installation manuelle du connecteur du serveur Web. Pour plus d’informations, consultez le problème enregistré sous le numéro 50586 dans JRun Updater 2 Known Issues*.

Notes

  • Le programme de mise à jour vers la version 6 de JRun 4 crée un répertoire, {jrunroot}/updater6-backup, qui contient une copie de tous les fichiers remplacés lors de la mise à jour.
  • Sous Mac OSX : exécutez le .bin à partir d’un interpréteur de commandes (shell). Stuffit ne peut pas décompacter ce fichier .bin et renvoie le message suivant : « Archive was compressed with an unknown compression method ».
  • Sous RedHat AS 3.0 : veillez à appliquer les mises à jour les plus récentes de votre système d'exploitation RedHat AS 3.0 avant d’effectuer la mise à jour vers la version 6 de JRun 4, afin d’éviter tout problème avec le compilateur Jikes. Voir la bogue 59348 dans le document known issues of Updater 5.
  • Sous RedHat AS 3.0 : veillez à installer les bibliothèques de compatibilité (Legacy Applications) afin d’éviter tout problème avec Apache. Voir la bogue 59367 dans le document known issues of Updater 5.
  • Le palliatif utilisé pour la mise à jour de JRun 4 vers la version 4 (dans le fichier jvm.config) pour des raisons de compatibilité avec JDK 1.5 doit être supprimé avant d’installer la mise à jour vers la version 6 :
    -Djmx.invoke.getters=true
  • Sous AIX : avant d’effectuer la mise à jour vers la version 6 de JRun 4, veillez à exécuter la commande 'slibclean' afin d’arrêter les éventuels modules en cours d’exécution dans la mémoire vive du kernel et des bibliothèques.

Améliorations

La mise à jour vers la version 6 de JRun 4 comporte les améliorations suivantes :

  • Pilotes JDBC mis à jour - La version 6 de JRun 4 comporte la version 3.4, build 50, des pilotes JDBC pour JRun.
  • Connecteurs - Le connecteur Apache prend désormais en charge les modules MPM (Multi-Processing Modules) d’Apache sous Unix. Diverses améliorations des performances, en particulier pour Microsoft IIS 6.0 (voir également 59653)
  • Serveur Web JRun (JWS) - JWS dispose désormais d’une fonctionnalité keep-Alive complète. Un nouveau niveau de journalisation permet de créer un log spécifique pour les requêtes HTTP. Pour plus de détails, consultez la section Problèmes résolus.
  • Prise en charge de Windows - JRun prend en charge Windows 2003 et IIS 6 depuis la version 3. JRun 4 n’est plus pris en charge sous Windows 98 et Windows ME à compter de la version 5.
  • Prise en charge de HP-UX - JRun est plus pris en charge sous HP-UX PA-RISC (1.1 et 2.0). Les version 11.0 et 11i (11.11) sont prises en charge. La version HP-UX IA64 n’est actuellement pas prise en charge.
  • Prise en charge de Mac OS X - La version 6 de JRun 4 prend en charge Mac OS X 10.4 (Tiger), ainsi que le JDK 1.5 sous OS X 10.4. Voir la note ci-dessous pour Mac OS X.
  • Prise en charge de Solaris - JRun 4 prend désormais en charge Solaris 10.
  • Prise en charge d’IBM AIX - JRun 4 prend désormais en charge IBM AIX 5.3.
  • Prise en charge d’Apache - JRun prend en charge les versions 1.3.2x-1.3.33 et 2.043-2.054 d’Apache. Pour les versions antérieures à Apache 2.x, une mise à jour d’Apache est nécessaire avant d’installer la mise à jour de JRun 4 vers la version 6.
  • Prise en charge de Linux - JRun 4 est maintenant pris en charge sous RedHat 8, Redhat AS2.1, AS3.0 et AS 4.0, ainsi que sous Novell Suse Linux 8.0.
  • Prise en charge de Sun JDK - JRun 4 prend en charge Sun JDK 1.5.0. JDK 1.5.0 est également pris en charge sous HP-UX PA-RISC (2.0 uniquement, sur des systèmes 11.0 et 11i).

Liste complète des systèmes d'exploitation pris en charge

Système d’exploitation JDK Serveur Web
Windows 2000 SP 4 Sun JDK 1.3/1.4/1.5
IBM JDK 1.3/1.4
IIS 5, Apache 1.3/2.0, iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
Windows XP Professional SP2 Sun JDK 1.3/1.4/1.5
IBM JDK 1.3/1.4
IIS 5.1, Apache 1.3/2.0, iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
Windows 2003 Enterprise Sun JDK 1.3/1.4/1.5
IBM JDK 1.3/1.4
IIS 6, Apache 1.3/2.0, iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
RedHat Linux 7/8/9 Sun JDK 1.3/1.4/1.5
IBM JDK 1.3/1.4
Apache 1.3/2.0 (version en bundle et version la plus récente), iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
RedHat AS 2.1/3.0/4.0 Sun JDK 1.3/1.4/1.5
IBM JDK 1.3/1.4
Apache 1.3/2.0 (version en bundle et version la plus récente), iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
Suse Linux 8.0 Sun JDK 1.3/1.4/1.5 Apache 1.3/2.0
Turbo Linux Sun JDK 1.3/1.4/1.5 Apache 1.3/2.0 (version en bundle et version la plus récente)
Solaris 7/8/9/10 Sun JDK 1.3/1.4/1.5 Apache 1.3/2.0, iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
IBM AIX 4.3/5.0/5.1/5.2/5.3 Sun JDK 1.3/1.4/1.5
IBM JDK 1.3/1.4
Apache 1.3/2.0, iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
HP-UX 11/11i (PA-RISC 1.1/2.0 only) Sun JDK 1.3/1.4/1.5 (1.5 sous PA-RISC 2.0 uniquement) Apache 1.3/2.0, iPlanet 4.1/6.0, NES 6.0/6.1, SunONE Web Server 6.1
Mac OS X 10.2/10.3/10.4 Sun JDK 1.3/1.4/1.5 Apache 1.3/2.0

Note sur la prise en charge du 64 bits

JRun prend actuellement en charge les environnements 32 bits et les machines virtuelles sous 32 bits, aussi bien pour le noyau serveur JRun que pour les connecteurs de serveur Web en bundle.

Les environnements intégralement sur 64 bits ne sont pas pris en charge (JVM sur 64 bits avec un kernel/OS sur 64 bits et sur une configuration matérielle sur 64 bits).

La seule configuration sur 64 bits prise en charge serait un environnements JRun 32 bits exécuté sur un système d'exploitation 64 bits et sur une configuration matérielle sur 64 bits.

Note sur Mac OS X et la version de JDK

JRun prend désormais en charge la plus récente version de Mac OS X, 10.4 (Tiger). JRun permet aussi d’utiliser JDK 1.5 avec ce système d'exploitation. JDK 1.5 ne fait pas partie de l’installation standard de Mac OS X, et doit donc être téléchargé et installé séparément sur le Mac. Lors du choix de la JVM sur Mac, JRun choisit la machine virtuelle pointée par le lien symbolique /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK. Sous OS X, ce lien pointe sur JDK 1.4.2 par défaut. Pour exécuter JRun avec le JDK 1.5, choisissez l’une des méthodes suivantes :

  • Faites pointer le lien 'CurrentJDK' sur le répertoire de JDK1.5 à l’aide des commandes suivantes :

    % rm CurrentJDK
    % sudo ln -sfh 1.5.0 CurrentJDK
  • Définissez JAVA_JVM_VERSION avec la version désirée :
    % export JAVA_JVM_VERSION 1.5

Notez que dans le fichier de configuration jvm.config, 'java.home' n’est pas utilisée pour détecter la JVM sous OS X.

Problèmes résolus avec cette version

La version 6 de JRun 4 comporte les corrections de bogues suivantes :

Pilotes de bases de données JDBC intégrés

Le pack de pilotes JDBC de la version 6 de JRun 4 est la version 3.4, build 50. Le pilote JDBC pour SQL Server prend en charge l’authentification NT à compter de cette version.  Voir la TechNote Updated DataDirect JDBC Drivers (version 3.4)* pour plus de détails.

Problèmes résolus avec cette version :

Oracle

  • 60039 – Lorsque SQLNET.AUTHENTICATION_SERVICES était désactivée sur le serveur Oracle, le pilote ne parvenait pas à établir une connexion.
  • 60019 – L’horodatage récupéré était en avance d’une heure sur celui du serveur de base de données lorsque le système d'exploitation était paramétré sur le fuseau horaire Est (USA).
  • 60066 – Le type de données TIMSTAMP WITH LOCAL TIME ZONE  était enregistré de façon incorrecte avec une heure de retard en période d’heure d’été.
  • 57661 – Un mot de passe expiré provoquait l’erreur « Net8 protocol error ».
  • 59202 – Blocage de 16 secondes sur resultset.close() lorsque setMaxRows() est utilisé.
  • 57263 - Blocage de 16 secondes sur statement.close() durant la récupération de clob.
  • 54831,55217 – Blocage d’Oracle sur clob en cas de caractère nul en fin de chaîne dans clob. (NLS_Characterset UTF8)
  • 55313 – Erreur de protocole Net8 avec un paramètre de sortie incorrectement enregistré.
  • 54937 – Message "[Macromedia][Oracle JDBC Driver]Cannot establish socket to redirected host/port" : absence d’identification de l’hôte ou du port.
  • 54994 – Les pilotes renvoient 16 octets pour char(8) sous Oracle. (NLS_Characterset JA16SJIS)
  • 55605 – Impossible d’insérer des caractères japonais dans une colonne clob. (NLS_Characterset UTF8)
  • 55308 – Limite de 2k pour un LONG renvoyé par une procédure stockée (limite portée désormais à 32k).
  • 55546 - CFTRANSACTION renvoie l’erreur ORA-01453.
  • 53182 – Les clob de 3 à 6 Mo environ renvoient 0 octet.
  • 53366 – Jeu de caractères "ELM8MSWIN1253" provoque un blocage pendant la récupération des CLOB.
  • 53357 - La récupération des CLOB renvoie 0 octet avec les jeux de caractères EL8MSWIN1253, JA16SJIS.
  • 52262 – Échec de l’actualisation d’un CLOB de plus de 2000 caractères avec les jeux de caractères EL8MSWIN1253, JA16SJIS.
  • 53466 - La récupération des CLOB génère l’exception java.lang.ArrayIndexOutOfBoundsException. Jeu de caractères : JA16SJIS.
  • 53477 - "No more data available to read" lors d’une connexion à Oracle 9i avec JA16SJIS.
  • 53758 - La récupération des CLOB génère l’exception ArrayIndexOutOfBoundsException avec Oracle9i. Jeu de caractères :JA16SJIS.
  • 53752 – Blocage en récupération de CLOB avec le jeu de caractères WE8ISO8859P15.
  • 53750 – Le pilote n’accepte pas une VARCHAR hors paramètres > 2000 caractères.
  • 53357 - Échec de l’actualisation des CLOB avec NLS_CharacterSet = WE8ISO8859P15.
  • 49775 - Erreur de protocole Net8 avec d’importantes quantités de données client variables. (sous charge légère)

SQL Server

  • 59000 – Le basculement sur les serveurs de secours ne fonctionne pas avec SQL Server lorsqu’une base de données n’est pas connectée.
    58950 – Windows uniquement (Type 2) Échec de l’authentification Windows avec des pilotes du commerce, message "cannot find DDJDBCAuth.DLL"
  • 56302 - @@Nestlevel dans une procédure stockée renvoie toujours 3.
  • 57050 - Certains interclassements (210-217) ne sont pas pris en charge.
  • 51266 – Message erroné "No more data available to read" lorsque le nombre maximum de connexions à la base de données est atteint.
  • 52851 – Fonctionnement en boucle du CPU lorsque SQL Server ferme une connexion inopinément.
  • 53556,53280 – Exception ArrayIndexOutOfBoundsException sur une instruction SQL de 2048 caractères.

Informix

  • 53223 – Erreur lors de la récupération de la date ('String to date conversion error') résolue avec le nouveau paramètre DBDATE URL. Voir la TechNote 1a3c2ad0* pour plus de détails.
  • 53592 – Échec de l’instruction Informix SELECT INTO TEMP.

Sybase

  • 57539 – Le fait d’attribuer à une procédure stocckée le même nom que la base de données déclenche une erreur.

DB2

  • 54536 - Impossible de se connecter à la base de données avec l’encodage Cp1114.
  • 53347 - "StripNewLines" pour DB2 ne gère pas les espaces blancs.
  • 53442 - "StripNewLines" avec des tabulations.

Tous les pilotes

  • 54937 – Modifié une exception de connexion pour identifier l’hôte et le port corrects.
  • 54826 – Erreur ArrayIndexOutOfBounds si les colonnes ne sont pas spécifiées dans un INSERT.
  • 53947 – Le dépassement de délai d’attente de CFQUERY dans des boucles de requêtes assez longues sous forte charge entraîne un nombre trop élevé de threads de supervision.

Connecteurs Web Server

Connecteurs SunOne, Netscape et IPlanet

Le modules NSAPI utilise désormais la dernière version des bibliothèques. Les modules individuels, qui étaient basés sur diverses versions de serveur Web, ont été regroupés dans un même module pour chaque plate-forme de base. Les modules UNIX et Linux sont jrun_nsapi.so. Le module Windows est jrun_nsapi.dll.

Connecteurs Apache

Le connecteur Apache prend désormais en charge les modules MPM (Multi-Processing Modules) d’Apache sous Unix.

Autres corrections de bogues

  • 56736 – Lorsque wsconfig est exécuté avec les switches -DWSConfig.PortScanStartPort=2901 et -DWSConfig.PortScanCount=2, le port de départ n’est pas le même sous Windows et Solaris. Sous Windows, La recherche débute sur le port 2901 et se poursuit sur le port 2902, puis s’interrompt. Sous Solaris, La recherche débute sur le port 2901 et se poursuit jusqu’au port 2903.
  • 59653 - IIS 6.0 prend en charge VectorSend, qui permet à une extension ISAPI de spécifier un vecteur de tampons et des handles de fichiers pour l’envoi des réponses à des requêtes concernant des données stockées dans plusieurs fichiers ou tampon, ce qui permet d’améliorer les performances.
  • 59720 – Lorsque le serveur JRun est arrêté, si un utilisateur envoie une requête à http://hote_local/index.jsp, il reçoit des résultats différents sous Windows 2003 et sous Windows XP/2000. Sous Win2003, le connecteur renvoie l’erreur 503. Sous XP/2000, le navigateur indique que le délai d’attente est dépassé. Désormais, le connecteur renvoie correctement l’erreur 503 à tous les systèmes sous Windows.
  • 59858 – Si le serveur Web est démarré avant Jrun, et si une requête lui parvient après le démarrage du serveur JRun mais avant que celui-ci ait fini de charger une application Web, les mappages ne seront pas chargés si mapCheck=0 -, même après le redémarrage de JRun.
  • 60181 – Les téléchargements de fichiers PDF en ligne sont enregistrés dans les journaux d’IIS avec le code 200, au lieu de 206, pour le contenu partiel lorsque le gestionnaire de caractères génériques de ColdFusion et un filtre ISAPI sont chargés (au niveau site ou global).
  • 60584 – L’installation de la version 6 n’effectue pas la mise à jour du module connecteur avec les connecteurs SunONE, Netscape et IPlanet. Le module connecteur doit être mis à jour manuellement après l’installation, en exécutant l’utilitaire Web Server Config et en désinstallant, puis réinstallant le connecteur.

JSP / Servlet / Web Engine

JWS et keep-alive

JWS prend maintenant en charge les connexions keep-alive, même avec un contenu dynamique (JSP/Servlets). La version antérieure ne gérait que le contenu statique.

Pour activer la fonctionnalité keep-alive, modifiez comme suit la section 'Web Service' de jrun.xml :

<service class="jrun.servlet.http.WebService" name="WebService">
   ---
   ---
   <attribute name="keepAlive">true</attribute>
   <attribute name="chunkedEncoding">true</attribute>
   ---
   ---
</service>

L’attribut 'chunkedEncoding' est nécessaire à la prise en charge de contenu dynamique. Pour du contenu dynamique, chunkedEncoding doit être mis à 'true' si 'keepAlive' est à 'true'. Le tableau suivant explique le comportement de JWS :

Requête Contenu keepAlive chunkedEncoding Connexion Réponse Remarques
HTTP 1.0 Statique false Sans objet fermeture HTTP 1.0 Sans objet avec HTTP 1.0
HTTP 1.0 Statique true Sans objet keep-alive HTTP 1.0  
HTTP 1.0 Dynamique false Sans objet fermeture HTTP 1.0  
HTTP 1.0 Dynamique true Sans objet fermeture HTTP 1.0 L’encodage en fragments n’étant pas disponible pour HTTP 1.0, la connexion sera fermée et keepAlive ne sera donc pas disponible.
HTTP 1.1 Statique false Sans objet fermeture HTTP 1.0 L’encodage en fragments n’est pas nécessaire si keepAlive n’est pas activé
HTTP 1.1 Statique true * keep-alive HTTP 1.0 Un en-tête Content-Length est envoyé, la valeur de chunkedEncoding est donc ignorée.
HTTP 1.1 Dynamique false Sans objet fermeture HTTP 1.0  
HTTP 1.1 Dynamique true false keep-alive HTTP 1.0 Combinaison déconseillée, car le navigateur attendrait en boucle.
HTTP 1.1 Dynamique true true keep-alive HTTP 1.1 Un en-tête de réponse HTTP 1.1 est renvoyé.  chunkedEncoding ne fonctionne qu’avec HTTP 1.1

Journalisation des requêtes JWS et HTTP

Une nouvelle fonctionnalité a été ajoutée dans la version 6 afin de journaliser les requêtes HTTP reçues par le serveur Web JRun. Cette fonctionnalité très utile pour l’analyse des accès est désactivée par défaut. Pour journaliser les accès, procédez comme suit :

  1. Dans la section 'LoggerService' jrun.xml, donnez la valeur true à 'accessEnabled', et supprimez la marque de commentaire de l’attribut 'accessFormat' pour définir les paramètres de format. La liste de tous les paramètres de format valides figure dans le fichier jrun.xml. Il est possible d’utiliser une combinaison de ces paramètres. JRun utilise un format d’accès par défaut si aucun format n’a été défini.
  2. Vérifiez que {log.level} est spécifié pour l’attribut 'filename', au lieu d’une valeur en dur comme 'event', etc.
<service class="jrunx.logger.LoggerService" name="LoggerService">
<attribute name="accessEnabled">true</attribute>
<attribute name="filename">{jrun.rootdir}/logs/{jrun.server.name}-{log.level}.log</attribute>

Un journal nommé <serveur>-access.log (par exemple default-access.log) sera créé pour recevoir les détails des requêtes HTTP.

JRun et le paramétrage de <load-system-classes-first> dans le fichier jrun-web.xml

Dans le fichier jrun-web.xml, le paramètre <load-system-classes-first> définit l’emplacement de chargement des classes pour l’application Web.

Si sa valeur est 'true', le chemin de classes du système a la priorité sur le chemin de classes des applications Web.

Si sa valeur est 'false', le chemin de classes local des applications Web est d’abord utilisé pour charger une classe ou une ressource. Si ces derniers n’y figurent pas, ils sont alors recherchés dans le chemin de classes du système.

La valeur par défaut est ‘true’, ce qui est très utile pour les cas où une application Web utilise des classes ou des ressources qui peuvent se trouver également dans le chemin de classes du système (par exemple dans jrun.jar).

Exemple de scénario de ce type : JRun est ivré avec le service Web Axis, qui possède une version de Log4j. Si une application Web nécessite une autre version de Log4j, donnez à <load-system-classes-first> la valeur 'false'.

Deux bogues ont été corrigées dans ce domaine :

  • 51723 – La fonctionnalité de fichier de configuration multiple d’Apache Log4J ne fonctionne pas dans Jrun 4.
  • 59842 - Apache log4j/commons.logging doit être renommé dans jrun.jar, pour permettre l’utilisation de votre propre fichier journal.

Autres corrections de bogues

  • 46136 – Exception ClassCastException dans jsp:useBean lors de la recompilation de la classe helper.
  • 48334 – Échec occasionnel des fichiers Include peu après le démarrage du serveur, avec divers messages d’erreur. Certains fichiers include n’affichent pas le html incorporé au bon emplacement dans la page.
  • 49197 – Impossible d’inclure dynamiquement (jsp:include) des fichiers ayant une autre extension que .jsp, .html et .txt dans une page jsp. La commande statique include(<@include>) fonctionne correctement.
  • 49287 - Si <jsp:include> inclut une jsp ou une servlet, et si celle-ci contient RequestDispatcher.forward(), la retransmission est interrompue et rien n’est renvoyé. JRun ne génère aucun erreur.
  • 50364 – La balise JRun4 jsp:forward provoque une exception IllegalStateException sur une actualisation de page ou une action POST lorsque la page cible est une page html.
  • 50436 – La tentative d’inclure une page html avec un dispatcher de requêtes provoque une exception ‘illegal state’. L’inclusion d’une page jsp fonctionne correctement.
  • 50471 - cgi.remote_host renvoie une adresse IP au lieu du nom du serveur. (seule remote_address devrait renvoyer une adresse IP)
  • 50959 – Des appels multiples de HttpServletResponse.setLocale provoquent l’apparition de plusieurs lignes Content-Language dans l’en-tête HTTP.
  • 53072 – Lorsqu’une commande JSP forward retransmet à une servlet et que celle-ci reçoit le flux de sortie, JRun génère une exception ‘illegal state’.
  • 54348 – Les en-têtes ne sont pas définis correctement (avec le jeu de caractères de Content-Type) en cas d’appel de response.setLocale().
  • 55876 - Exception java.lang.IllegalStateException en cas d’utilisation de jsp:include pour une servlet qui appelle ensuite RequestDispatch.forward()
  • 58765 – Si une requête est retransmise à une servlet qui appelle response.getOutputStream puis ferme le flux, JRun renvoie une erreur ClosedIOException ‘Response has already been closed’ et l’exception IllegalStateException. Cependant, le code se termine correctement.
  • 59049 - JRun crée plusieurs instances d’une classe de servlet même si la servlet n’implémente pas le modèle SingleThreadModel. Le cas se produit si le délai d’attente après init() est trop long.
  • 59255 – La méthode request.setAttribute() accepte et paramètre des attributs avec la valeur 'null'. Les spécifications des servlets précisent que si la valeur d’un attribut est 'null', l’attribut ne doit pas être défini et, s’il existe déjà, il doit être supprimé de la requête.
  • 59396 – Une requête destinée à une servlet qui n’existe pas renvoie correctement une erreur 404. Si la servlet est alors placée à l’emplacement voulu, et si l’attribut 'reload' est true pour l’application Web, la requête ne sera pas servie sauf si le serveur est redémarré. Une erreur 404 continue à être renvoyée.
  • 59729 – Le mappage des servlets JRun4 n’est pas conforme aux spécifications des servlets et ne laisse pas les mappages explicites prendre la priorité sur les mappages implicites.
  • 59857 - JWS ne répond plus lorsque keep-alive est activé. (Voir la note ci-dessus, JWS et keep-alive)
  • 59884 – D’après les spécifications J2EE/Servlet 2.3, si un Filter (une classe qui implémente javax.servlet.Filter) renvoie une exception dans la méthode init(), le filtre doit être désactivé (et retiré de la chaîne de filtres). JRun ne retire pas le filtre de la chaîne de filtres, mais à ce stade le filtre n’a pas été initialisé correctement et ne peut pas fonctionner.
  • 60167 - lastAccessTime n’est pas défini correctement pour HTTP Session.
  • 60464 – Une exception Class Cast Exception est générée si une classe dépendante est modifiée dans la JSP.
  • 60573 - JRun ne compile pas les fichiers java en cas d’appel à partir d’une jsp en utilisant javac (Sun JDK).
  • 60574 - JRun ne donne pas la priorité au paramètre 'java.home' de jvm.config lors du choix du compilateur.
  • 60375 – Échec de JDBC Session Persistence avec les bases de données MySQL.

Pools de connexions

  • 52855- Les connexions JDBC ne sont pas allouées correctement lorsqu’elles sont créées par le client autonome. Si le code du client ouvre plusieurs connexions, la même connexion physique est associée à toutes. Lorsque deux connexions sont ouvertes et que la première est fermée, une exception ‘Connection Closed’ est ensuite générée à la tentative de fermer la seconde.

EJB

  • 53355 – Les mises à jour de la base de données se produisent avant ejbStore dans 1.1 CMP. (observé avec SQL Server)

Divers

Le service Windows JRun et l’arrêt ou le redémarrage du système d'exploitation

  • 56758 – Le service Windows JRun (jrunsvc.exe), build 80735, n’arrête pas JRun dans les regles lors du redémarrage d’un ordinateur sous Windows.

La notification d’arrêt est désormais gérée correctement.

REMARQUE : sur certains ordinateurs, lorsque le ou les serveurs JRun mettent beaucoup de temps à se fermer, le mécanisme de dépassement de délai des services de Windows termine le processus JRun. Dans ce cas, il est possible de modifier le délai d’attente des services Windows en changeant la valeur de WaitToKillServiceTimeout dans la clé de registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

Par défaut, cette valeur est de 20 secondes. La modification de cette valeur peut affecter la fermeture du système et les performances au redémarrage.

Autres corrections de bogues

  • 54079 – Échec de démarrage du serveur avec la JVM IBM 1.4.1 sous Windows lors de la recherche d’une classe spécifique Sun.
  • 57058 – Le serveur cesse parfois d’enregistrer les métriques dans metrics.log et la sortie standard.

    Un nouvel attribut a été ajouté à SchedulerService.
    <service class="jrunx.scheduler.SchedulerService" name="SchedulerService">
    <attribute name="bindToJNDI">true</attribute>
    <!—Le service scheduler doit ici tenter de
      replanifier des tâches par suite de la non disponibilité de Active Handler
      Threads. La valeur par défaut est de 60 secondes -->
    <attribute name="droppedTaskRescheduleTime">[délai en secondes] </attribute>
    </service>
    La valeur de l’attribut 'maxHandlerThreads' de SchedulerService ne doit jamais être supérieure à celle de 'activeHandlerThreads’, car les threads engendrés par SchedulerService sous forte charge ne s’arrêtent pas lorsqu’ils passent en attente. Ces threads en attente consomment beaucoup de ressources système.
  • 58303 – Sous RedHat EL 3.0 ou 2.1, l’administrateur peut enregistrer un serveur JRun distant mais ne peut pas recevoir des informations sur ces serveurs. Le statut de ces serveurs distants indique ‘not running’ lorsque le fichier /etc/hosts n’est pas correctement configuré. Il existe deux façons de résoudre ce problème :
    1. Vérifier que le fichier /etc/hosts comporte les entrées suivantes :

      127.0.0.1 localhost.localdomain localhost
      <IP> <nom_hôte>

      Note - remplacer <IP> par l’adresse IP du serveur et <nom_hôte> par le nom d’hôte du serveur
    2. Si la méthode (1) ne résout pas le problème :

      Ajoutez les arguments suivants au fichier jvm.config :

      java.args=
      -Xms32m -Xmx128m -Dsun.io.useCanonCaches=false
      -Djava.rmi.server.hostname=<hostname/IP>
      Enregistrez ensuite le serveur distant en utilisant les valeurs spécifiées dans le fichier jvm.config pour 'nom_hôte' ou 'IP'.
  • 59885 – Le lanceur supprime les arguments de jvm.config java.args lorsqu’il est utilisé avec wsconfig (lui-même utilisé sans les arguments -start, -ntservice).
  • 59886 – Les autorisations basées sur des rôles de JRun ne fonctionnent que dans le domaine principal. Une prise en charge des autorisations a été ajoutée pour le domaine local.