7. Changements dans cette version

7.1. Correctifs de bogues

CDI/Weld

1051375 - Si plusieurs beans.xml existent dans un war déployé dans un EAR, tous les beans CDI seront enregistrés deux fois

Dans la version précédente d'EAP 6, lorsqu'un déploiement EAR contenait un WAR de sous-deploiement avec plusieurs fichiers beans.xml, comme par exemple dans WEB-INF/beans.xml et WEB-INF/classes/META-INF/beans.xml, tous les beans étaient enregistrés deux fois et le déploiement échouait. Ceci a été corrigé en modifiant le processeur de déploiement afin qu'il puisse tenir en compte de cette possibilité et que ces déploiements cessent d'échouer au déploiement.
1029099 - NPE quand on réplique le bean CDI dans un cluster EAP 6.1.0

L'ID de session créé dans les versions antérieures de JBoss EAP contenait une source complète dans les métadonnées de déploiement de bean (utilisées pour créer un ID de session). Cela entrainait les beans déployés dans les différents nœuds du cluster à être recréés si un ID de session était réutilisé pour accéder à un nœud différent. Une exception NullPointerException apparaissait également dans les journaux du nœud peu de temps après.

Un nouveau code a été introduit pour obtenir un chemin d'accès relatif, à la place d'un chemin d'accès absolu. Cela signifie que les beans ne sont plus recréés et que l'exception NPE n'est plus présente.
1050963 - Correctif permanent pour: org.jboss.weld.exceptions.DeploymentException: nom du bean WELD-001414 ambigu

La validation ambigue d'un nom de bean n'était pas isolée dans les déploiements contenant plusieurs sous-déploiements, et cela provoquait des DeploymentException dans certains scénarios. Ceci a été résolu avec une mise à niveau du composant Weld dans cette version de Red Hat JBoss EAP 6.
1070069 - Conversation expirée réactivée de façon inattendue dès la prochaine requête

Dans les versions précédentes de JBoss EAP 6, il a été constaté qu'une conversation pourrait être activée de façon inattendue et associée à une demande même après l'expiration de la conversation, résultant en l'exception NonExistentConversationException.

C'était parce que, dans une application JSF, Weld n'a pas vérifié correctement l'état de la conversation au début des requêtes.

Cette version du produit inclut une activation du contexte de conversation mise à jour et une procédure d'invalidation pour vérifier l'état de conversation plus à en détails. Ainsi, des conversations expirées ne sont plus associées par erreur aux demandes.

CLI

988283 - CLI GUI - le dialogue d'attribut écriture de valeur de chaîne doit inclure une valeur à guillemets doubles dans la commande générée

Essayer de définir une valeur à l'aide de l'outil jboss-cli qui contenait une propriété ne faisait que de sauvegarder le caractère $ de la valeur à la place de la propriété, sauf si la valeur entière était contenue entre guillemets doubles. C'est parce que l'analyseur de ligne de commande CLI analysait par erreur les expressions {X} $ en $, sauf si celles-ci étaient contenues entre guillemets doubles.

L'analyseur de ligne de commande a été réparé dans cette version, donc les attributs contenant des propriétés seront correctement analysés même s'il ne sont pas contenus entre guillemets doubles.
1007831 - CLI GUI - l'opération add (ajouter) échoue pour client-config et endpoint-config en webservices

Dans les versions précédentes de JBoss EAP 6, une opération Ajouter, qui n'avait pas d'argument, était assimilée à une opération qui ne nécessitait aucune saisie de la part de l'utilisateur de l'interface CLI.

Cela amenait l'utilisateur à exécuter l'opération sans fournir l'argument obligatoire name (nom), ce qui conduisait à un échec.

Dans cette version, l'opération add (ajouter) sans argument est maintenant interprétée par la logique d'interface comme une opération ayant nécessité l'argument name (nom).

Maintenant, avant d'autoriser l'utilisateur à exécuter une opération add qui, selon la descritpion du modèle de gestion, ne nécessite pas d'argument, on exigera de l'utilisateur qu'il fournisse l'argument name (nom) requis.
1019232 - jboss-cli.sh lançait l'exception NullPointerException quand on utilisait la fonctionnalité de saisie semi-automatique via la touche TAB sur un noeud de source de données

Dans les versions précédentes de JBoss EAP 6, l'outil jboss-cli envoyait une exception et se fermait quand l'utilisateur tentait d'utiliser la fonctionnalité de saisie semi-automatique via la touche TAB dans certaines circonstances.

Cela était dû à une gestion inadequate des exceptions par l'analyseur de commandes dans ces situations et cela a été corrigé dans cette version.
1031173 - jboss-cli.bat ne fonctionne pas quand EPA est installé dans un répertoire avec des espaces

L'outil jboss-cli ne démarrait pas correctement dans Microsoft Windows quand JBoss EAP 6 était installé dans un répertoire ayant des espaces ou autres caractères spéciaux, tels que des parenthèses dans son chemin d'accès. Par exemple, le message d'erreur suivant apparaissait si JBoss EAP 6 avait été installé dans le répertoire C:\JBoss EAP\jboss-PAE-6.2 :
Erreur: Could not find or load main class EAP\jboss-eap-6.2\bin\jboss-cli-logging.properties

Ce problème a été résolu dans cette version en changeant la façon dont l'outil jboss-cli déclare et utilise les chemins d'accès dans Microsoft Windows. Ainsi, il peut être utilisé sans solution de contournement dans les installations JBoss EAP 6 dans des répertoires qui ont des espaces ou autres caractères spéciaux dans leur chemin d'accès sur les systèmes Microsoft Windows.
1026418 - La commande passée comme argument n'est pas exécutée quand elle est en cours d'acceptation d'un certificat SSL.

Lorsque vous démarrez JBoss EAP 6 CLI avec une commande passée en argument, si ce serveur a invité l'utilisateur à accepter un certificat de serveur, il aura journalisé cette invite comme une erreur. Il en résulte que toute commande passée en argument est alors ignorée, car ces commandes sont exécutées uniquement quand aucune erreur n'est survenue.

Ce problème a été résolu en considérant l'invite d'acceptation de certificat comme une sortie normale au lieu d'une erreur. Ainsi, une commande passée comme argument lors du démarrage de l'interface CLI est maintenant exécutée avec succès après que l'utilisateur ait accepté le certificat du serveur.

CLI, Remoting

1037574 - OOM lors de l'exécution de plusieurs opérations CLI sans doute suite à un mauvais nettoyage

Les utilisateurs des versions précédentes de JBoss EAP 6 ont peut-être rencontré des erreurs OutOfMemory en effectuant plusieurs opérations par le biais de l'interface de ligne de commande.

La question a été attribuée à des fuites de mémoire causées par un mauvais nettoyage de la mémoire lors de l'utilisation de l'interface CLI.

Le problème a été corrigé dans cette version du produit.

Chargement des classes

1060997 - testConnection doit prendre en considération le classloader de déploiement

On a découvert un bogue qui pouvait entraîner l'envoi d'exceptions lorsque vous testez une source de données dans d'anciennes versions de JBoss EAP. L'exception se présentait lors de l'utilisation du protocole LDAP dans la balise « connexion-url » datasource. Le produit ne parvenait pas à instancier InitialContextFactory parce que le module "org.jboss.as.connector" n'était pas en mesure d'accéder à certaines classes fournies par JDK (comme com.sun.jndi.ldap.LdapCtxFactory). Cela aboutissait à un échec de test de connexion de source de données lorsque la source de données « connexion-url » utilisait le protocole "ldap://".

Ce problème a été résolu en ajoutant une dépendance sur sun.jdk pour le module org.jboss.as.connector. Cela rend les classes JDK requises accessibles depuis le module de connecteur et le test de source de données utilisant le CLI avec l'opération "test-connection-in-pool" réussit.
1054972 - L'initialisation de MBeans utilise le mauvais TCCL

Dans les versions précédentes de JBoss EAP, il a été constaté qu'une application TCCL (de l'anglais Thread Context Class Loader) n'était pas correctement établie lors de l'initialisation de MBeans contenus dans les fichiers .sar. Cela signifiait que les ressources du déploiement n'étaient pas disponibles pour le MBean lors de l'initialisation. Avec cette mise à jour du produit, le TCCL est maintenant réglé correctement autour de l'appel à l'initialisation du MBean et les MBeans peuvent désormais accéder à des ressources de déploiement lors de l'initialisation.
971076 - Module "org.jboss.log4j.logmanager" nécessite une dépendance sur le module "javax.mail.api"

Dans les versions précédentes de JBoss EAP 6, org.jboss.log4j.logmanager n'indiquait pas ses dépendances sur javax.mail.api dans son module.xml.

Cette version ajoute cette dépendance au module logmanager.

Clustering

990567 - ClassCastException quand on stocke la session http session dans PostgreSql

On a constaté un problème ayant une influence sur le stockage de la session HTTP avec Postgresql. Avec la configuration suivante de jdbc-store, une erreur de ClassCastException s'est produite, comme le message d'erreur en exemple. Les valeurs de la session HTTP étaient persistées, mais l'application ne permettrait pas de redéployer avec le même message d'erreur.
<binary-keyed-jdbc-store datasource="java:jboss/datasources/testDS" preload="true" passivation="false" purge="false">
 <binary-keyed-table prefix="b">
  <id-column name="id" type="VARCHAR(255)"/>
  <data-column name="datum" type="BYTEA"/>
  <timestamp-column name="ver" type="BIGINT"/>
 </binary-keyed-table>
</binary-keyed-jdbc-store>
14:24:21,262 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (http-/127.0.0.1:8080-1) ISPN000136: Execution error: java.lang.ClassCastException: java.lang.Class cannot be cast to org.infinispan.loaders.bucket.Bucket...

Ce problème a été résolu par une mise à niveau du composant et les données de session HTTP peuvent être persistées avec succès dans une base de données Postgresql.
917010 - CacheException: Échec lors du désenregistrement des mbeans lors de la fermeture du serveur

Les versions précédentes de JBoss EAP 6 contenaient un bogue dans le composant Infinispan qui entraînait l'exception suivante au moment de la fermeture du serveur :
WARN [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-1) ISPN000032: Problems un-registering MBeans: org.infinispan.CacheException: Failure while unregistering mbeans

L'erreur n'empéchait pas la fermeture du serveur et était causée par des demandes multiples de fermeture (à partir de CacheService et EmbeddedCacheManagerService) envoyées aux instances de cache unique.

Ce problème a été résolu par une mise à niveau du composant Infinispan.
963448 - Mauvaise gestion d'exception dans CoreGroupCommunicationService#handle

Dans les versions précédentes de JBoss EAP 6, il a été constaté que CoreGroupCommunicationService #handle correspondait à une mauvaise gestion des exceptions, affectant l'appelant de la classe.

La classe s'est avérée cacher des exceptions et retourner des valeurs null à la place. Cette valeur peut produire des comportements inattendus et imprévus chez les appelants.

Dans cette version, la réponse null sera traitée par le gestionnaire de verrous distribués, cependant l'utilisation de CommandDispatcher dans les futures versions du produit résoudra le problème en permanence.
1039585 - Fuite de la mémoire de la session clusterisée

Les versions précédentes de JBoss EAP 6 contenaient un bogue qui pouvaient conduire à une exception OutOfMemoryException dans les sessions web distribuées. L'exception survenait si une session web expirait sans que les objets de verrou créés par le gestionnaire de session soient libérés ou détruits. Tandis que les sessions web continuaient d'expirer, les objets de verrou (lock) résiduels s'accumulaient dans la mémoire. Finalement, cela conduisait à une exception OutOfMemoryException. Le seul recours était de redéployer l'application web.

Dans cette version du produit, les objets de verrou sont correctements libérés et donc, l'exception OutOfMemory n'a plus lieu.
956904 - Infinispan remote-store nécessite des remote-servers mais le paramétrage n'est pas rendu obligatoire pour le modèle mgmt

Un problème a été découvert dans la gestion de la configuration remote-store d'Infinispan. L'option remote-store avait besoin que la valeur de l'option remote-server soit définie, mais cela n'était pas le cas, entraînant ainsi un échec du remote store. Ce problème a été résolu en rendant le paramètre remote-server obligatoire, pour éviter une configuration remote-store non valide.

Dans cet exemple, la commande CLI est incomplète et un avertissement apparait.
[standalone@localhost:9990 /] /subsystem=infinispan/cache-container=web/distributed-cache=dist/remote-store=REMOTE_STORE:add(remote-servers=[])     {
  "outcome" => "failed",
  "failure-description" => "JBAS014706: [0] is an invalid size for parameter remote-servers. A minimum length of [1] is required",
  "rolled-back" => true,
  "response-headers" => {"process-state" => "reload-required"}
}

Dans cet exemple, la commande CLI est complète.
[standalone@localhost:9990 /] /subsystem=infinispan/cache-container=web/distributed-cache=dist/remote-store=REMOTE_STORE:add(remote-servers=[{"outbound-socket-binding" => "fred"}])
{
  "outcome" => "success",
  "response-headers" => {"process-state" => "reload-required"}
}

Gestion des domaines

1015303 - Le domaine de sécurité LDAP doit avoir des délais d'attente configurables

Cette version de JBoss EAP 6 connaît une amélioration qui permet l'utilisation de propriétés personnalisées sur les connexions sortantes de LDAP.

Dans les versions précédentes du produit, les connexions LDAP sortantes étaient créées parmi un ensemble limité de propriétés, laissant le reste du comportement par défaut. En conséquence, il n'était pas possible pour les propriétés personnalisées d'être définies pour contrôler divers aspects tels que la connexion et la lecture des délais d'attente.

Dans cette version, les propriétés personnalisées peuvent maintenant être définies pour les connexions LDAP sortantes avec un code semblable au suivant :
<ldap name="LocalLdap" url="ldap://localhost:10389" search-dn="uid=wildfly,dc=simple,dc=wildfly,dc=org" search-credential="password1!">
 <properties>
  <property name="one" value="two"/>
  <property name="three" value="four"/>
 </properties>
</ldap>
1074999 - Application disparaissant de la section Gestion des déploiements de la console EAP

Dans les versions précédentes de JBoss EAP 6, le statut d'un déploiement n'était pas mis à niveau dans le système de fichiers quand la console était en cours d'utilisation.

De ce fait, utiliser à la fois le scanner de système de fichiers et la console pour gérer le statut d'un déploiement aboutissait à une interprétation erronée de la part du scanner, à savoir, que le déploiement n'était pas déployé.

Dans cette version du produit, la console et le scanner de système de fichiers à partager peuvent maintenant échanger l'état du déploiement et les utilisateurs peut maintenant utiliser les deux outils d'administratifs pour gérer les déploiements.
1035232 - Le mode de domaine EAP ne fonctionne pas correctement avec le gestionnaire de sécurité

Dans les anciennes versions de JBoss EAP 6, les serveurs d'un domaine géré ne pouvaient pas démarrer correctement, s'ils étaient configurés pour utiliser un Java Security Manager, sans spécifier le nom de classe du gestionnaire de sécurité.

Par exemple, cela se fait facilement en spécifiant -Djava.security.manager soit dans domain.conf. soit en tant que paramètre de ligne de commande en utilisant le gestionnaire de sécurité par défaut.

Ce problème surgissait car une propriété système sans valeur était passée par les contrôleurs hôte sur leurs serveurs gérés, avec la valeur true. Cela revenait à dire que les serveurs avaient essayé maladroitement d'utiliser un gestionnaire de sécurité Java ayant pour nom de classe true.

Ce problème a été résolu dans cette version en ajoutant des vérifications supplémentaires aux propriétés système du contrôleur hôte pour qu'une propriété système soit passée à des serveurs gérés correctement. Ainsi, en utilisant un domaine géré et en utilisant le gestionnaire de sécurité par défaut en spécifiant -Djava.security.manager, tout devrait fonctionner comme prévu.
1047515 - Le mode de domaine ne démarre pas dans le JDK d'IBM

Un problème qui empêchait souvent le démarrage de JBoss EAP 6 dans les environnements JDK d'IBM JDK sur les machines Windows a été résolu dans cette version.

La question a été tracée à la manière sont les données binaires (c'est-à-dire un octet[]) écrites dans java.lang.Process.getOutputStream() par le processus parent sont captées sur System.in par le processus enfant. N'importe quel octet dont le bit est égal à 1 arrive brouillé à la réception, produisant la sortie suivante dans le journal de console :
[Host Controller] 16:44:06,419 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("start") failed - address: ([
[Host Controller] ("host" => "master"),
[Host Controller] ("server-config" => "server-one")
[Host Controller] ]): java.lang.IllegalStateException: JBAS010986: Host-Controller is already shutdown.
[Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:175)

Un Contrôleur de processus de domaine géré EAP communique avec les processus du serveur qu'il gère par ce mécanisme, ce qui signifie que le problème affectait les domaines gérés EAP 6.

Dans cette version du produit, toutes les communications vers un processus managé sur stdin ont été encodées en base 64, ce qui atténue le problème et les serveurs de domaine géré démarrent maintenant correctement sur Windows sur le JDK d'IBM.
1054776 - ClientConfigurationImpl ne doit pas traduire l'adresse IP en nom d'hôte

Dans les versions précédentes de JBoss EAP, lorsqu'il vous arrivait de créer une instance de client de contrôleur et que vous lui passiez une adresse IP pour se connecter, l'adresse IP était traduite en interne au nom d'hôte de la machine.

Puis, quand le client tentait une connexion, il utilisait le nom d'hôte plutôt que l'adresse IP.

Non seulement, cela introduisait une surcharge superflue en impliquant le serveur DNS, mais dans certains scénarios de déploiement très spécifiques, cela entraînait le client à essayer de se connecter à une adresse IP différente de la même machine que celle où une instance de JBoss EAP était liée, entraînant un échec de la tentative de connexion.

Le problème a été résolu dans cette version; le code client contrôleur ne traduit pas l'adresse IP donnée en interne en nom d'hôte et il utilise l'adresse IP (plutôt que le nom d'hôte correspondant) pour faire une connexion.

Notez que ce correctif n'affecte pas le scénario quand un nom d'hôte est passé à la méthode de l'usine du client contrôleur. Dans un tel cas, le nom d'hôte sera traduit en adresse IP et cette adresse sera utilisée, comme on s'y attend.
1072915 - les esclaves ne peuvent pas se reconnecter à un master redémarré quand le RBAC est actif

Dans les versions précédentes de JBoss EAP 6, quand on se reconnectait au contrôleur hôte maître (master), le modèle de configuration était ajouté au mauvais endroit.

Cela signifiait que la connexion à nouveau au contrôleur-hôte maître avec RBAC actif échouait.

Dans cette version, le modèle est ajouté à l'emplacement voulu, pour que l'hôte esclave puisse se connecter sans problème.
1040621 - Impossible d'utiliser des déploiements avec le même nom de runtime dans un domaine

Dans les versions précédentes de JBoss EAP 6, la vérification des doublons des attributs de nom de runtime de déploiement d'un groupe de serveurs au démarrage était trop agressive. Elle envoyait une erreur (par erreur) au démarrage s'il y avait un nom de runtime dans le domaine, au lieu de se concentrer sur un groupe de serveur unique.

Ainsi, mettre des déploiements multiples dans un domaine ayant le même nom de runtime se traduisait par un échec de démarrage, même si ces déploiements n'étaient pas mappés au même groupe de serveurs.

Par exemple :
JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
...
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1348,9]
...
Message: JBAS014664: An element of this type named 'example.war' has already been declared

Dans cette version, la validation de l'unicité des noms de runtime a été déplacée de l'analyseur XML à la logique d'exécution de l'opération, et la logique de validation a été ajustée afin d'ignorer les doublons non associés au même groupe de serveurs.

Plusieurs déploiements avec la même valeur de nom de runtime peuvent maintenant coexister dans un domaine, tant qu'ils ne sont pas mappés au même groupe de serveurs.
1076066 - Impossible de promouvoir le --backup slave HC au niveau du master, et charger à nouveau, sans déplacer le domain.cached-remote.xml

Dans les versions précédentes de JBoss EAP 6, un bogue empêchait un esclave contrôleur hôte ayant été reconfiguré pour se comporter comme master de charger la configuration de domaine mise en cache lors du redémarrage. C'est parce que le master nouvellement promu chargeait la configuration du fichier domain/configuration/domain.xml au lieu du fichier domain/configuration/domain.cached-remote.xml.

Dans cette version du produit, si un esclave HostController démarrait avec l'option --backup est reconfiguré pour agir en tant que master et est ensuite rechargé pour saisir le changement, le fichier domain.cached-remote.xml qu'il maintenait quant il exécutait en tant que sauvegarde, sera automatiquement détecté et utilisé.
1038465 - le serveur de liaisons de sockets distant n'est pas arrêté quand la ressource est supprimée

Dans les versions précédentes de JBoss EAP 6, le service de liaisons de sockets sortantes distant n'était pas arrêté quand la ressource était supprimée.

Cela signifie qu'il n'était pas possible d'ajouter une liaison de socket sortante de destination distante avec le même nom, car l'opération :add (ajouter) échouait dans la mesure où il y avait déjà un service enregistré avec ce nom.

Dans cette version, quand une ressource de liaison de socket sortante de destination distante est supprimée, le service correspondant est arrêté.

De ce fait, il est possible de supprimer ou d'ajouter une liaison de socket sortante de destination distante sans interruption.
1110065 - Créer un serveur sur un esclave de domaine, puis définir une propriété système échoue si effectué en mode lot

Dans les versions précédentes de JBoss EAP 6, lorsque le HostController traitait une mise à jour de sa configuration, il produisait des opérations pour appliquer les modifications à tous les serveurs en cours d'exécution sous sa coupe.

Le problème est que le contrôleur hôte créait également des opérations pour les serveurs non en cours d'exécution pour qu'ils ajoutent la propriété de système "env", ce qui résultait en erreur "Aucun gestionnaire d'événements pour les composites d'opération à l'adresse".

Cette version de produit ne crée plus les opérations de modification de l'environnement des serveurs non en cours d'exécution et les erreurs n'ont plus lieu.
1093866 - La config HC de l'esclave "admin-only-policy" n'est pas implémentée correctement

Dans les versions précédentes de JBoss EAP 6, un contrôleur hôte esclave démarré en mode admin-uniquement ne peut pas se connecter au contrôleur de domaine maître pour obtenir la configuration sur tout le domaine.

De ce fait, quand un contrôleur hôte est lancé avec --admin-only (admin-uniquement), et que son host.xml a admin-only-policy="fetch-from-master" de défini, l'esclave ne peut se connecter au master pour obtenir la configuration sur tout le domaine. L'esclave ne pourra pas démarrer.

Cela empêche l'esclave --admin-only d'utiliser RBAC, sauf si une copie du fichier de configuration de l'ensemble du domaine est stockée localement comme domain.cached-remote.xml et que l'esclave est lancé avec --cache-dc.

Dans cette version, la logique de connexion esclave a été corrigée et l'esclave peut se connecter au master et obtenir la configuration sur tout le domaine, lui permettant ainsi d'obtenir la startégie de configuration sur l'ensemble du domaine RBAC.
1024109 - NPE dans DelegatingServerInventory

Les demandes de gestion envoyées à un contrôleur hôte immédiatement après que le contrôleur hôte ait été lancé pouvaient échouer avec une exception de type NullPointerException. C'était parce qu'il y avait un lapse de temps entre le moment où le contrôleur hôte était en mesure de recevoir les demandes et le moment où le système de gestion de serveur avait bien démarré. Cette période était généralement moins d'une seconde, mais toutes les demandes reçues à ce moment là échouaient.

Ce problème a été résolu dans cette version, pour que le contrôleur hôte ne ne reçoive les demandes que lorsque le système de gestion de serveur était pleinement démarré. Par conséquent, il n'y a plus de lapse de temps pendant lequel les demandes reçues déclenchent une exception NullPointerException parce que le système de gestion du serveur n'est pas encore pleinement démarré.
1085122 - ApplyRemoteMasterDomainModelHandler doit appliquer les valeurs de la ressource racine

Dans les versions précédentes de JBoss EAP 6, il a été constaté que la ressource racine de domaine du contrôleur de domaine n'était pas appliquée aux contrôleurs hôtes esclaves. Au lieu de cela, les contrôleurs d'hôtes esclaves utilisaient leur propre ressource racine.

Cela signifie que lors de la connexion directe au contrôleur de domaine esclave, les numéros de version de la ressource du domaine racine correspondaient à la version du contrôleur de domaine esclave, donc la configuration du domaine n'était pas homogène parmi les contrôleurs du domaine.

Dans cette version du produit, le processus d'enregistrement d'esclave a été mis à jour pour appliquer la ressource du domaine racine et les numéros de version sont maintenant les mêmes à travers l'ensemble du domaine.
1016995 - La fonctionnalité de superposition de déploiements n'est pas en mesure de remplacer les bibliothèques d'application.

Dans les versions précédentes de JBoss EAP 6, la fonctionnalité Superposition de déploiements (Dployment Overlay) ne fonctionnait pas comme documenté. Elle n'écrasait pas les bibliothèques de jar d'application comme elle en était censée. Des modifications ont été apportées pour permettre à la fonctionnalité de superposition de déploiement d'écraser les bibliothèques de jar d'applications, et elle se comporte maintenant conformément à la documentation.
1077838 - isSensitiveValue de la classe SensitiveVaultExpressionConstraint utilise un index erroné dans la méthode java.lang.String.substring

Dans les anciennes versions de JBoss EAP 6, la classe SensitiveVaultExpressionConstraint utilisait un index de chaînes erroné quand on avait plusieurs {} dans la valeur de l'attribut d'écriture.

Ainsi, l'utilisation d'un index erroné causait l'apparition de l'exception StringIndexOutOfBoundsException.

Dans cette version, la méthode isSensitiveValue de la classe SensitiveVaultExpressionConstraint est fixée de façon à recevoir l'index qui convient et StringIndexOutOfBoundsException n'apparaît plus.
1074560 - L'autorisation EAP Management envoie une exception quand le groupe LDAP contient une barre oblique

Les versions précédentes de JBoss EAP contenaient un bogue qui empêchait le caractère barre oblique (/) d'agir en tant que séquence d'échappement correctement lorsqu'il était utilisé dans un groupe LDAP sur un serveur Windows Active Directory LDAP. De ce fait, EAP Management lançait l'exception NamingException. Cette version inclut une mise à jour qui veille à ce que le caractère d'échappement agisse correctement et l'exception n'est plus présente.
1077536 - Utilisation élevée du processeur par le client JMX Monitoring. RBAC semble en être à l'origine.

Un problème de performance affectant la requête JMX a été identifié, où la charge CPU était beaucoup plus élevée que prévu dans les versions précédentes de JBoss EAP. La cause du problème était que le contrôle d'accès basé sur les rôles (RBAC) vérifiait l'adresse de chaque requête, peu importe si que cette adresse soit pertinente à la requête JMX ou non. Pour résoudre ce problème, le traitement des requêtes a été changé afin de vérifier si l'adresse est pertinente à la requête JMX et si non, le traitement sera évité. Le résultat de ce changement est que la charge CPU de JMX Monitoring est de nouveau à un niveau normal.
1038397 - Le contrôle d'accès basé sur les rôles (RBAC) ne fonctionne pas si Java Security Manager (JSM) est actif

Quand JBoss EAP 6 exécutait Java Security Manager activé, le système de contrôle d'accès basé sur les rôles (RBAC) était en fait désactivé car dans ce cas, tous les utilisateurs authentifiés étaient traités comme des superutilisateurs. La seule façon d'utiliser l'accès RBAC était de désactiver le gestionnaire de sécurité Java.

Ce problème a été résolu dans cette version en faisant que tous les accès à AccessControlContext aient lieu en dehors de l'action privilégiée. En conséquence, RBAC est maintenant toujours en vigueur lors de l'activation du Java Security Manager.
901275 - L'utilisation d'un archivage sécurisé de propriétés système lance l'exception java.lang.SecurityException

Les versions précédentes de JBoss EAP 6 échouaient à l'amorçage si une propriété système contenant une expression d'archivage sécurisé était utilisée.

C'était parce que les ressources de propriétés système de la configuration XML étaient traitées avant les ressources d'archivage sécurisé. Cela signifiait que l'archivage sécurisé n'était pas disponible comme source de résolution d'expressions. Toutes les ressources utilisant un attribut d'archivage sécurisé induisaient l'erreur suivante :
java.lang.SecurityException: JBAS013322: Vault is not initialized

Dans cette version du produit, si une expression de valeur de propriété système ne parvient pas à résoudre, une deuxième tentative est faite plus tard dans le processus de démarrage, après l'installation de l'archivage sécurisé (s'il est configuré). Cette action résoud le problème et les systèmes utilisant des expressions d'archivage sécurisé peuvent maintenant démarrer comme prévu.
1092220 - Les journaux d'audit n'enregistrent pas les opérations de démarrage correctement.

Les versions précédentes de JBoss EAP 6 contenaient des problèmes d'efficacité dans le système de journalisation d'audit des opérations de gestion exécutées lors de l'amorçage du système :
  • Les opérations de démarrage utilisent des fonctionnalités particulières qui leur permettent d'exécuter en parallèle. L'installation de l'enregistrement d'audit ne prenait pas cela en considération, ce qui se traduisait par des journaux désorganisés et confus.
  • Les enregistrements de journaux étaient mis en suspend en attente de l'exécution de l'opération permettant que les enregistrements d'audit soient vidés de la file d'attente avant l'exécution des opérations qui gèrent l'ajout de gestionnaires de journaux. Ces documents ne figuraient pas dans aucun journal.

Voici les conséquences de ces problèmes :
  • Les journaux d'opérations qui avaient lieu avant l'addition de log handlers d'audit n'ont pas été enregistrés.
  • Les opérations d'addition en extension n'étaient pas journalisées.
  • Des détails internes d'exécution qui n'auraient pas dû l'être étaient enregistrés, donnant l'impression que certaines opérations étaient exécutées deux fois.
  • Les opérations parallèles de démarrage n'étaient pas organisées de façon à refléter le flux logique d'opérations qui provient des analyseurs XML, mais étaient non consignées dans des segments de sous systemes individuels, avec des segments ordonnés au hasard.

Dans cette version du produit, les enregistrements de journaux en file d'attente ne sont pas vidés avant que tous les log handlers aient eu une chance d'être installés et la manière dont le suivi des événements à enregistrer est fait est plus sophistiqué, ce qui permet un bon suivi de l'exécution des opérations qui ont lieu pendant le démarrage en parallèle.

Toutes les opérations qui se produisent pendant le démarrage sont maintenant enregistrées, sans qu'aucun détail inutile interne à leur exécution ne soit inclus. Les opérations sont organisées de façon cohérente en deux groupes qui reflètent la façon dont le serveur organise la séquence de démarrage fondamentalement. Les opérations qui s'exécutent en parallèle pendant le démarrage sont rapportées dans l'ordre dans lequel elles ont initialement été fournies par l'analyseur XML.
1092213 - AccessAuditContext domainUUID non défini quand l'en-tête domain-uuid est défini

Les versions précédentes de JBoss EAP 6 contenaient un bogue qui consistait à ce que PrepareStepHandler crée un UUID et définissait "operations-headers" = > "domaine-uuid" sur une opération, mais ne passait pas ensuite cet UUID à AccessAuditContext.

Dans une opération de domaine gérée pour une opération sur le contrôleur de domaines, cela signifiait que le champ domainUUID de l'enregistrement de journal d'audit n'avait aucune valeur, toutefois le champ d'opération qui montrait l'opération qui était appelée incluait un en-tête d'opération domaine-uuid.

Ce problème a été résolu dans cette version du produit.
1092206 - OperationContextImpl.readResourceForUpdate assume que toutes les ressources représentent une config persitante

Dans les versions précédentes de JBoss EAP 6, la logique d'exécution des opérations assumait que toutes les ressources de gestion représentaient une configuration persistante avec la méthode readResourceForUpdate pour un OperationStepHandler.

De ce fait, l'opération probe de la ressource subsystem=transaction/log-store=log-store et l'opération delete de la ressurce subsystem=transaction/log-store=log-store/transactions=* ne pouvaient pas être invoquées par un admin dans le rôle Operator.

Ce problème a été résolu dans cette version.
1092203 - L'opération d'écriture non autorisée ne peut obtenir la journalisation de l'audit si log-read-only="false"

Les versions précédentes de JBoss EAP 6 contenaient un bogue qui empêchait l'enregistrement d'une opération « écriture » invoquée par un utilisateur non autorisé si l'attribut « log-read-only » sur la ressource de gestion audit-logging était défini sur false.

C'est parce que le contrôleur de modèle utilisait « acquisition de verrou de contrôleur » comme condition pour déterminer si une opération devait être signalée comme une opération d'« écriture » dans le journal. Lorsque le contrôle d'accès basé sur les rôles (RBAC) était activé et qu'une opération non autorisée était réalisée, l'erreur avait lieu avant que le verrou du contrôleur soit pris.

En conséquence, les opérations d'écriture non autorisées n'étaient rapportées dans le journal d'audit que si « log-read-only » était défini sur false. Si « log-read-only » était défini sur true, l'enregistrement journal considérait par erreur que l'opération était une opération de « lecture ».

Ce problème a été résolu dans cette version du produit.
1049102 - Le CLI n'affiche pas le statut de l'application quand le runtime-name est différent du nom de déploiement

Dans les versions précédentes de JBoss EAP 6, le gestionnaire d'opérations qui déterminait le statut d'un déploiement utilisait le nom de déploiement pour trouver le service de déploiement au lieu d'utiliser son nom de runtime.

Ainsi, si un déploiement avait un nom de runtime différent de son nom de gestion, une tentative de lecture du « statut » de son attribut entraînait une réponse No metrics available (Aucun paramètre disponible).

Par exemple :
[standalone@localhost:9999 /] deploy /home/ABC.ear --name=ABC.ear --runtime-name=XYZ.ear

[standalone@localhost:9999 /] /deployment=ABC.ear:read-attribute(name=status)
{ "outcome" => "success", "result" => "no metrics available" }

Dans cette version du produit, le gestionnaire utilise le nom de runtime quand il cherche le service de déploiement pour que le statut soit correctement retourné. La réponse de l'exemple ci-dessus est maintenant :
[standalone@localhost:9999 /] /deployment=ABC.ear:read-attribute(name=status)
{ "outcome" => "success", "result" => "OK" }
1034700 - l'opération whoami ne fonctionne pas quand le gestionnaire de sécurité est actif

L'opération :whoami n'était pas exécutée correctement lorsque JBoss EAP 6 était en cours d'exécution avec le gestionnaire de sécurité Java activé. Si l'on tentait d'exécuter cette opération dans cette situation, cela entraînerait l'exception IllegalArgumentException. Cela se produisait en raison de situations AccessControlContext non valides au cours desquelles l'identification de l'appelant était incorrecte.

Ce problème a maitenant été corrigé dans cette version par l'accès de AccessControlContext en dehors de l'action privilégiée. De ce fait, l'opération :whoami sera exécutée correctement si JBoss EAP 6 exécute avec Java Security Manager activé.

Gestion de domaines, scripts et commandes

1023444 - Le domaine ne parvient pas à démarrer avec la paramètre de configuration sur Windows 32bit JDK

Les anciennes versions de JBoss EAP pouvaient échouer au démarrage quand elles exécutaient dans un environnement Windows 32-bit JDK avec la configuration mémoire par défaut.

Dans cette version du produit, les paramètres de configuration par défaut ont été diminués pour assurer le démarrage sur une grand nombre de JVM.

Les clients qui se fient aux paramètres de configuration JVM sont avisés de revoir leur configuration et d'ajuster les paramétres JVM selon leurs besoins.

Gestion de domaine, Services web

987898 - Écrire dans l'attribut wsdl-url à des fins de point de terminaison WS 'Unknown attribut wsdl-url' au lieu de 'Attribute wsdl-url is not writable'

Cinq attributs des points de terminaison de Services Web SOAP déployés (nom, contexte, classe, type et wsdl-url) n'étaient pas accessibles dans les outils de gestion. C'était parce qu'ils n'étaient pas exposés au modèle de gestion par le sous-système de Web Services. Ce problème a été résolu dans cette version, et les attributs peuvent maintenant être configurés dans le sous-système de webservices à l'aide de l'interface de gestion CLI.

EE

1056799 - JBMETA-371: DefaultPropertyReplacer + PropertyResolver est endommagé pour les expressions d'archivage

Dans les versions précédentes de JBoss EAP 6, l'expression résolvant la logique des classes DefaultPropertyReplacer et PropertyResolver (utilisée pour l'analyse des fichiers de descripteur de déploiement) suppose que l'expression contenue entre "${" et "}" est d'un format fixe, où tout char ":" de l'expression représente un séparateur entre un nom de propriété et une valeur par défaut.

Cela signifie que les expressions d'archivage de sécurité dans les descripteurs de déploiement ne pouvaient pas être correctement analysées, car ":" était toujours utilisé dans ces expressions et non pas comme un séparateur qui précède une valeur par défaut. Les expressions d'archivage étaient évaluées incorrectement avec le contenu de l'expression après la première apparition de ":" considéré comme valeur résolue.

Dans cette version du produit, lorsque la fin d'une expression est détectée, avant de retourner le contenu de l'expression après la première apparition de »: « comme une valeur résolue, le résolveur vérifie d'abord si l'expression entière peut être résolue.

Les expressions d'archivage de sécurité peuvent maintenant être utilisées dans des fichiers de descripteurs de déploiement où les expressions sont autorisées en général.

EJB

1093128 - Les valeurs de délai d'expiration des transactions client distant sont codées en dur

Les versions précédentes de JBoss EAP 6 avaient un problème pouvant donner lieu à des transactions de client distant s'étendant sur plusieurs serveurs avec des délais d'expiration ayant lieu plus tôt ou plus tard que prévu.

La question s'est posée parce que les valeurs des délais d'expiration ne se propageaient pas parmi les serveurs correctement, ce qui fait que le système se fiait à la valeur d'expiration codée en dur (300 secondes)

Ce problème a été résolu dans JBoss EAP 6.3.0
1059911 - L'horloge @Schedule EJB Timer n'utilise pas le fuseau horaire lors du calcul du prochain délai d'expiration

Dans les versions précédentes de JBoss EAP 6, si l'horloge @Schedule EJB Timer utilisait un fuseau horaire qui était différent de celui utilisé par le serveur, les invocation de minuterie qui suivent l'appel initial ne se déclenchaient pas correctement. Cette version résout ce problème et tous les appels de minuterie se déclenchent comme prévu lorsque les fuseaux horaires diffèrent entre Serveur et @Schedule.
1035216 - ArrayIndexOutOfBoundsException durant le recouvrement périodique sur EJBTransactionRecoveryService

Un problème intermittent entre le recouvrement périodique et EJBTransactionRecoveryService résultait en l'exception ArrayIndexOutOfBoundsException.
[com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ArrayIndexOutOfBoundsException: 0
 at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:112)
....

La cause principale du problème est que la création d'un élément XAResource ne figurait pas dans la boucle de logique associée et cela conduisait à l'erreur d'index de tableau. Cet élément a maintenant été déplacé pour qu'il soit dans la boucle de logique et ainsi, le recouvrement périodique n'est plus en conflit avec le EJBTransactionRecoveryService.
1017673 - ConcurrentModificationException dans TimerService.getTimers()

Si un bean tentait de créer une nouvelle minuterie en même temps qu'un autre thread était en train d'appeler la méthode getTimers(), l'exception ConcurrentModificationException apparaissait. Cela se produisait parce que la méthode getTimers() n'appelait pas synchronized() sur les horloges.

Ce problème est résolu dans cette version, et l'implémentation de la méthode getTimers() du service d'horloge appelle maintenant correctement synchronized() sur les minuteries.
1031199 - Le support de cache EJB peut générer une grande rétention des tâches annulées dans son DelayedWorkQueue d'exécuteur programmé.

L'implémentation de cache des EJB @Stateful de JBoss EAP 6 utilise un exécuteur programmé pour la gestion de la logique @StatefulTimeout. Lors de l'accès à un bean, son job de timeout précédent est annulée, et un nouveau job est programmé quand l'appel est terminé.

Par défaut, l'annulation d'une tâche d'un exécuteur ne le retirait pas de la file d'attente.

Cela causait une fuite de mémoire graduelle, car les tâches annulées demeuraient dans la file d'attente.

Dans cette version, l'exécuteur programmé peut être configuré de façon à supprimer la tâche de la file d'attente après une annulation. Cela évite la fuite de mémoire.
1045105 - le code de client ejb distant convertit '$$' en '$' dans les mots de passe

Les versions précédentes de JBoss EAP 6 contenaient un bogue qui amenait PropertiesBasedEJBClientConfiguration à étendre les mots de passe contenant le signe de dollar double ($$) comme s'il s'agissait d'une expression. Cela aurait pu causer le transfert des mauvais mots de passe entre le serveur et le client.

Le PropertiesValueResolver a été modifié dans cette version de façon à ce qu'il n'étende pas les mots de passe par défaut. Cela a résolu le problème.

Si l'expansion est requise, elle peut être activée en définissant `jboss-ejb-client.expandPasswords` à true.
1055896 - Ne parvient pas à obtenir une exception en pass-by-reference

Il y a un bogue qui empêche les servlets d'obtenir des exceptions EJB en pass-by-reference, même s'ils ont été configurés pour le faire. Ceci a été corrigé dans cette version.
901324 - AroundInvokeAnnotationParsingProcessor doit échouer quand on trouve davantage de méthodes avec l'annotation @AroundInvoke dans la classe

Dans les anciennes méthodes de JBoss EAP 6, les méthodes @AroundInvoke n'étaient pas toutes vérifiées par les classes.

De ce fait, la première méthode trouvée était utilisée, et les autres ignorées.

Dans cette version du produit, le déploiement échoue quand il y a plusieurs méthodes @AroundInvoke, alertant le développeur du problème.
1056214 - Les problèmes d'invocation EJB sont dues à l'allocation élevée de chaînes inutiles

On a traité un problème de performance dans cette version de JBoss EAP 6. Le problème provenait de StatefulComponentInstanceInterceptor qui effectuait une petite concaténation dans une instruction de débogage de journal pour chaque appel. Les allocations supplémentaires suivantes pouvaient causer une activité accrue de Garbage Collection lors d'invocation d'EJB stateful, conduisant à un effort de traitement par appel plus élevé. Cette version du produit a incorporé un patch en amont qui résout ce problème et les efforts de traitement par appel ont considérablement diminué.

EJB, Remoting

1098879 - Le client EJB échoue initialement si le cluster utilisé pour l'invocatin EJB avec l'opération « ould not create a connection for cluster node ClusterNode{} -> » échouait avec le statut WAITING

Dans les versions précédentes de JBoss EAP 6, il y avait un problème avec les clients EJB se connectant à un cluster quand un ou plusieurs noeuds de cluster étaient spécifiés par la première connexion.

Cela était surtout un problème qui avait lieu sur la plateforme Windows, et qui causait l'échec intermittent de la première invocation EJB en raison d'une mauvaise synchronisation de chaînes.

Ce problème a été résolu dans cette version et n'a plus lieu.

Hibernate

1023994 - la conversion de java.util.Calendar en java.util.Date échoue - HHH-8643

Cette version de JBoss EAP 6 contenait un correctif de bogue dans le composant Hibernate qui entraînait le lancement de l'exception IllegalArgumentException lorsque vous définissez un paramètre TemooralType.DATE ou TemporalType.TIMESTAMP dans une requête JPA. Le paramètre est destiné à pouvoir utiliser un calendrier ou une valeur de date, mais cette interchangeabilité ne fonctionnait pas comme prévu. Le problème a maintenant été corrigé et l'exception n'est plus présente lors de l'utilisation de paramètre de type TemporalType dans les requêtes.
1048709 - NPE en query.list sur Native SQL, en utilisant le cache

Dans les versions précédentes de JBoss EAP 6, l'utilisation de scalaires dans une requête, lorsque vous utilisiez le cache de requête Hibernate, amenait les utilisateurs à apercevoir une exception NullPointerException. Voici un exemple de requête qui produisait l'exception :
query.addScalar("emp_first_name");

Le problème était causé par le code qui tentait d'identifier automatiquement le type d'Hibernate qu'il fallait pour gérer le scalaire (StringType, par exemple). Dans cette version, le code a été modifié pour identifier correctement le handler qui convient.

Dans les versions antérieures à 6.3.0, définir explicitement le type Hibernate qui se trouve dans le scalaire de la requête évitera le NPE :
query.addScalar("emp_first_name", new StringType());
1070423 - les pilotes de bases de données HHH-8983 peuvent ajouter des avertissements aux handles d'instructions, qui, en s'accumulant, pouvaient consommer un montant de mémoire élevé.

Dans les versions précédentes de JBoss EAP 6, il a été constaté que les pilotes de base de données pouvaient attacher des avertissements aux handles d'instruction, qui pouvaient s'accumuler et consommer des quantités de mémoire élevés. Le problème se présentait lors de l'utilisation de types de Timestamp avec des mappages datetime de Sybase. Les avertissements émis par les pilotes de Sybase ultérieurs pouvaient exagérer l'empreinte mémoire des mises à jour par lots. Cette question a été abordée dans cette version et ne se présente plus.
1073076 - HHH-3482: UnsupportedOperationException dans StatelessSession

Instances de UnsupportedOperationError lancées quand l'utilisation d'une StatelessSession et la sauvegarde de ManyToOne ont été adressés dans JBoss EAP 6. L'erreur était causée par un appel à la méthode getTimestamp() non implémentée pour la StatelessSession. L'erreur UnsupportedOperationError ne se présente plus.
1057742 - Dialecte PostgreSQL & H2 incorrect pour uplets « count-distinct » d'attributs composites

JBoss EAP 6 a été mis à jour pour permettre l'utilisation de parenthèses autour de listes d'attributs composites dans des requêtes distinct-count dans MySQL et autres bases de données. Ce n'était pas autorisé dans les versions précédentes du produit et se traduisait par une exception dans PostgreSQL. Cette version permet au dialecte d'utiliser les parenthèses sans lever d'exception.

HornetQ

1056216 - Modifier le comportement de connexion initial pour la connexion au cluster

Si une instance en cluster de HornetQ perdait sa connexion à d'autres nœuds de cluster, les tentatives de reconnexion pouvaient entraîner une boucle infinie. Pour une configuration de cluster statique, toute tentative de connexion initiale pouvait être tentée infiniement, en ignorant le paramètre reconnect-attempts. Pour une configuration de cluster dynamique, si le nœud a été déconnecté entre le moment où il a reçu une notification sur le nœud faisant partie de la topologie de cluster et la connexion initiale, les tentatives de reconnexion continuaient indéfiniement. Ce problème a été résolu et la logique de regroupement utilise maintenant le paramètre reconnect-attempts pour les tentatives de connexion initiale et les tentatives de reconnexion à la fois.
1089838 - Transversale scheduledReferences complète pour chaque appel à ScheduledDeliveryHandlerImpl$ScheduledDeliveryRunnable.run()

Dans les versions précédentes de JBoss EAP 6, si un grand nombre de messages étaient programmés sur un interval réduit, un excès de charge en mémoire en résultait.

La cause principale de ce problème était que pour chaque instance de messages sur le point d'être consommés, l'ensemble de la liste scheduledReferences liée était traversé inutilement.

Ce problème a été résolu dans cette version.
1063864 - Backport de HornetQ-1278 dans JBoss EAP

Dans les versions précédentes de JBoss EAP 6, Scheduled Delivery Handling effectuait un cycle complet de recherches en série sur une liste de livraisons planifiées.

Cela pouvait causer des problèmes de performance car le système utilisait des ressources consommant un montant de mémoire élevé pour procéder aux nombreuses livraisons planifiées en attente.

Cette version du produit a implémenté une liste ordonnée et une recherche allant jusqu'au nombre total d'expirations. La liste de recherche fonctionne maintenant beaucoup plus vite sans charge de mémoire trop élevée.
1089843 - Messages d'avertissement WARN parasites après que XmlDataImporter ait effacé le fichier temp

Dans les versions précédentes de JBoss EAP 6, quand XmlDataImporter importait des messages volumineux, des messages d'avertissement WARN parasites étaient journalisés.

La cause principale de ce problème était que lorsqu'on importait des messages volumineux, le XmlDataImporter créait un fichier temporaire et le supprimait quand la tâche d'importation était complétée.

Lorsque vous importiez un autre message volumineux, la fonction XmlDataImporter essayait à nouveau de supprimer le fichier temporaire et, étant donné que le fichier n'était plus présent, enregistrait le message WARN.

Ce problème a été résolu dans cette version.
1096942 - Client non en mesure d'envoyer les messages - HornetQException[errorCode=100 message=HQ119016: queue has been removed cannot deliver message, queues should not be removed when grouping

Dans les versions précédentes de JBoss EAP 6, les utilisateurs rencontraient des problèmes avec les groupements clusterisés. Les messages de routage pouvaient être interrompus et donner des réponses non valides.

Dans cette version, la communication entre les noeuds a été améliorée, comme l'a été le processus de récoltage des groupes pour d'éviter ceci ou autres messages parasites qui pouvaient se produire dans les regroupement en cluster.
1089844 - Policy Fail peut déposer des messages avant d'envoyer l'exception au client

Dans les versions précédentes de JBoss EAP, la police "fail" address-full-policy d'HornetQ déposait dans la majorité des cas des messages sans envoyer une exception au client.

Ceci résultait en des messages déposés sans exception quand une adresse était remplie.

Ce problème a été résolu pour que le blocage envoie toujours le résultat dans une exception au client lorsque l'adresse est remplie et que les envois qui ne bloquent pas entraînent une exception sur le client lorsque des crédits supplémentaires sont demandés par le serveur.
1089846 - Toutes les méthodes de ClientSessionImpl qui implémentent XAResource sont suceptibles d'envoyer une exception non-XAException à la TM

Dans les versions précédentes de JBoss EAP, si une transaction XA impliquant HornetQ expirait, il était possible qu'HornetQ envoie une exception non-XAException au gestionnaire de transactions.

Le problème a été identifié dans l'implémentation de javax.transaction.xa.XAResource, et a été résolu dans cette version.
1089849 - Messages toujours reçus individuellement après certains scénarios de reconnection.

Dans les versions précédentes de JBoss EAP 6, le consommateur client recevait des messages individuellement dans certains scénarios, comme par exemple, après une défaillance. Ce processus était très efficace.

Ce problème a été résolu dans cette version.
1089851 - Éviter la possibilité d'une NPE pendant le processus de dépagination

Dans les versions antérieures du produit, une exception NullPointerException (NPE) était probable au cours de la remise de messages et du processus de pagination.

Ce problème a été résolu dans cette version.
1089841 - Corriger l'ordonnancement de totalIterator()

Dans les versions précédentes de JBoss EAP 6, toute opération de gestion qui listait des messages listait incorrectement les messages paginés avant les messages déjà envoyés.

D'autres problèmes de ce genre ont également été identifiés dans des cas de renvois à nouveau.

Ce problème a été fixé en rectifiant l'ordre dans lequel l'itérateur prend les messages avant de les envoyer aux opérations de gesiton.
1089835 - Le taux max de ClientConsumer ne prend pas effet si ServerLocator's consumerMaxRate <=0

Dans les anciennes versions de JBoss EAP 6, la méthode d'API Core createConsumer(String queueName, String filter, int windowSize, int maxRate, boolean browseOnly) ignore le paramètre maxRate si ConnectionFactory (ou ServerLocator) a défini le maxRate comme valeur par défaut à zéro ou à une valeur inférieure.

La cause principale de ce problème est la logique défectueuse de la méthode createConsumer. Elle a été corrigée dans cette version.
1089842 - la méthode listMessagesAsJSON ne parvient pas à lister les messages si la propriété du filtre contient le carctère \n character.

Dans les versions précédentes de JBoss EAP 6, le filtrage échouait si le message contenait le caractère suivant (\n) (nouvelle ligne) dans une chaîne ou toute autre propriété.

La cause principale de ce problème est la logique défectueuse de la méthode listMessagesAsJSON, qui ne prenait pas en compte le caractère indiquant une nouvelle ligne.

Ce problème a été résolu dans cette version.

IIOP

1064644 - StackOverflowError quand org.jboss.as.jacorb.rmi.InterfaceAnalysis analyse javax.ejb.EJBObject

Dans les versions précédentes de JBoss EAP 6, il a été constaté que, selon le moment d'un changement de contexte de chaîne, les EJB activés IIOP peuvaient échouer au déploiement, ce qui causait une erreur StackOverflowError.

Ce problème remonte à une mauvaise synchronisation de chaîne dans org.jboss.as.jacorb.rmi.WorkCacheManager.

Ce problème a été résolu dans cette version et l'erreur StackOverflowError n'a plus lieu.
1052237 - Backport JacORB #904 CDRInputStream.read_string doit pouvoir gérer une taille de chaîne 0 facilement

La fonction CDRInputStream.read_string gère une chaîne vide malencontreusement, en la calculant avec une longueur de zéro (0), ce qui entraîne une exception de marshalling. Un QoS a été ajouté pour permettre à CDRInputStream.read_string d'interopérer avec les ORB qui n'encodent pas correctement les chaînes vides.

Installateur

1034062 - Valeurs de configuration d'offset (décalage) de port en double dans les fichiers d'hôtes de domaine.

Il y a un bogue qui dupliquait automatiquement les décalages de port quand on cochait l'option Configure an offset for all default port bindings. Ce problème a été corrigé dans cette versions.
1062602 - L'installateur accepte le mot de passe de l'utilisateur admin sans caractère alphabétic.

Dans les versions précédentes de JBoss EAP 6, il a été constaté que l'utilitaire d'installation graphique n'honorait pas le nom d'utlisateur ou les restrictions de mot de passe qui gouvernent la création d'un utilisateur.

Ce problème a été résolu dans cette version et l'installateur (GUI) adhère maintenant aux règles de restriction de nommage et de mot de passe comme prévu.

JCA

1088470 - Fuite du ConnectionListener si TSR lance l'exception IllegalStateException et NPE dans SemaphoreArrayListManagedConnectionPool

Un bogue qui se trouvait dans les anciennes versions de JBoss EAP 6 entrainait des fuites du ConnectionListener quand le TSR lançait l'exception IllegalStateException et NPE dans SemaphoreArrayListManagedConnectionPool.

Ce problème a été résolu dans cette version du produit.

JDR

1069850 - empêche un NullPointerException dans JDR CommandLineMain

Dans les versions précédentes de JBoss EAP 6, une exception NullPointerException était lancée quand une exception était lancée du JDR CommandLineMaine. Ce problème a été résolu dans cette version.

JMS

1033495 - L'opération CLI commitPreparedTransaction CLI n'est pas disponible en mode de domaine

Dans les versions précédentes de JBoss EAP 6, les opérations de gestion sur les ressources de servuer hornetq n'étaient pas disponibles en mode de domaine. Ce problème a été résolu dans cette version.

JPA

1040733 - Fuite de mémoire dans l'intégration Hibernate JPA / JBoss AS

Une fuite de mémoire TA pouvait se produire dans le serveur d'applications lorsque vous utilisiez le CLI pour obtenir des statistiques JPA pour les déploiements d'applications qui utilisent les requêtes nommées JPA. Le problème a été résolu dans cette version du produit.

JSF

1029387 - WFLY-2493 EL ne peut pas accéder aux méthodes/champs publics de classes non publiques

Dans les versions précédentes de JBoss EAP 6, le BeanELResolver n'essayait pas de substituer le contrôle d'accès Method.invoke pour accéder aux méthodes publiques ou aux champs de classes non publics.

Cela causait des problèmes quand on essayait d'accéder à la méthode publique ou au champ d'une classe non publique via Expression Language (EL) et entraînait le message d'erreur suivant :
"java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"

Ce problème a été résolu en appelant setAccessible(true) le cas échéant dans la mise en œuvre de l'EL. Les méthodes publiques ou les champs de classe non publics sont maintenant accessibles via EL
1017242 - FacesMessages ne fonctionne pas correctement avec une application de contexte racine.

Dans les versions précédentes de JBoss EAP 6, il a été constaté que le champ d'application JSF Flash n'était pas restauré correctement lors des redirections quand l'application était liée au contexte racine. Cela signifiait que les messages FacesMessages ne fonctionnaient pas correctement dans les applications de contexte racine.

Cette version du produit voit le composant Mojarra mis à niveau vers la dernière version en amont, ce qui résout le problème et FacesMessages fonctionne maintenant correctement même pour les applications de contexte racine.
1052265 - JAVASERVERFACES-3080: Issue quand plus d'un f:viewParam est inclus dans f:metadata.

En raison d'un bogue en amont, avec plus d'un f:viewParam à l'intérieur de f:metadata ne fonctionnant pas dans les versions précédentes de JBoss EAP 6. Une mise à niveau vers le composant JSF a résolu ce problème et maintenant, plus d'un f:viewParam peut maintenant être incluss dans la f:metadata.
1054051 - La configuration du slot JSF ne fonctionne pas correctement en tant que configuration par défaut

Lorsqu'un emplacement JSF supplémentaire était installé dans la racine du répertoire de modules, le slot principal de JSF n'était pas ajouté comme configuration JSF valide. Le déploiement d'une application JSF qui tentait d'utiliser l'implémentation JSF principale échouait avec le message :
org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS012656: Default JSF implementation slot 'main' is invalid

La cause de ce problème a été résolue et le slot « principal » est maintenant toujours considéré comme une des implémentations JSF valides. Ainsi, lorsqu'un emplacement JSF supplémentaire est ajouté à la racine du répertoire de modules, les applications JSF qui font plutôt usage de l'implémentation JSF principale peuvent être déployées avec succès.

Ouverture de session

1066597 - l'attribut du formateur change à chaque fois qu'il est traité

Un bogue qui entraînait la méthode HandlerOperations.equalValue() à retourner toujours false dans les versions précédentes de JBoss EAP 6 a été corrigé avec l'inclusion d'un correctif en amont. Ce bogue se présentait parce que la méthode utilisait un nom de propriété incorrect lors de la comparaison des valeurs. Ne se présente plus dans cette version du produit.
1080991 - Action privilégiée manquante dans Messages#getBundle() de jboss-logging

Dans les versions précédentes de JBoss EAP 6, exécuter un gestionnaire de sécurité activé sans autorisation suffisante entraînait des erreurs lorsque l'on tentait de récupérer un paquet de messages.

De ce fait, une exception se présentait quand on tentait d'obtenir un paquet de messages quand les permissions de chargement de classe n'étaient pas activées.

Dans cette version, récupérer des paquets de message se fait maintenant dans un bloc de privilège. Les exceptions ne se produisent plus lors de la récupération du paquet de messages lorsqu'un gestionnaire de sécurité est activé.
1088618 - Représentation en chaîne du cache d'infos throwable

Les informations de trace de pile n'était pas forcément stockés correctement dans les versions précédentes de JBoss EAP 6. Par conséquent, les données pouvaient se perdre lors de la sérialisation des événements de journalisation Log4J.

Pour résoudre ce problème, Log4J a été modifié pour mettre en cache la trace de la pile (throwable information) lors de la désérialisation. Cela garantit que les informations de trace de pile ne seront pas perdues lors de la serialization.
1017881 - /subsystem=logging/logger=org.jboss.as.quickstarts.logging:assign-handler ne peut pas être exécuté en mode de lot

Dans les versions précédentes de JBoss EAP 6, l'attribut de nom des opérations de journalisation composites était ajouté et lu à partir du modèle.

Ainsi, le nom de famille d'une opération composite était le seul nom de handler utilisé, ayant pour résultat le même nommage d'handler ajouté plusieurs fois.

Dans cette version, l'attribut de nom n'est plus copié dans le modèle et est lu à partir de l'opération elle-même. L'ajout de handlers dans une opération composite fonctionne maintenant comme prévu.
1095516 - Les objets POJO sont maintenant retirés de logging.properties quand on les retire de JBoss Config XML

Dans les versions précédentes de JBoss EAP 6, quand la définition d'un POJO était supprimée du fichier de configuration du serveur, les références au POJO étaient retirées du fichier logging.properties.

Si un POJO du même nom était créé plus tard à nouveau, JBoss EAP indiquait qu'il y avait une entrée double dans logging.properties.

Ce problème a maintenant été résolu et les références aux objets POJO qui n'existent plus sont maintenant retirées du fichier logging.properties.
1073053 - Le journal d'audit d'EAP 6.2 doit afficher la version EAP au lieu de la version AS

Dans les anciennes versions de JBoss EAP 6, le journal d'audit affichait un numéro de version incorrect

Cela a été corrigé dans cette version et le numéro de version est affiché comme prévu.
1066606 - Utiliser un log4j appender comme custom-handler doit invoquer activateOptions si nécessaire

Dans les versions précédentes de JBoss EAP, la modification d'une propriété d'un gestionnaire personnalisé qui était un appender log4j n'invoquait pas les OptionHandler.activateOptions() sur l'appender si l'appender implémentait OptionHandler. Il a fallu un redémarrage des ressources de journalisation pour que la modification prenne effet. Dans cette version, la méthode d'activation est maintenant invoquée si les propriétés sont modifiées dans l'appender log4j et un redémarrage n'est plus nécessaire pour les appenders OptionHandler.
1070452 - System.out.println() ne fonctionne pas quand on utilise une journalisation par déploiement

Les versions précédentes de JBoss EAP 6 comportaient un bogue qui empêchait la méthode System.out.println() d'imprimer dans les fichiers journaux lorsque la journalisation par déploiement était en cours. Ce bogue a été résolu par un correctif en amont.

Nommage

1014414 - Le nommage distant envoie la même exception pour des raisons différentes

Dans les versions précédentes de JBoss EAP 6, la même exception était levée en réponse à un certain nombre d'erreurs de connexions qui pouvaient survenir lorsqu'un client distant de nommage ne parvenait pas à se connecter à un hôte. Ce comportement était sous-optimal car il ne donnait aux utilisateurs aucune indication de l'erreur rencontrée pour un serveur donné.

Dans tous les cas, l'exception envoyée était la suivante :
javax.naming.NamingException: Failed to connect to any server. Servers tried: [remote://localhost:4447]

Dans cette version, les exceptions envoyées s'alignent davantage en rapport à la cause réelle de l'échec.

Si les informaions sur l'hôte ou le port sont incorrects, l'exception CommunicationException sera envoyée, indiquant que la connexion a expiré :
javax.naming.CommunicationException: Failed to connect to
any server. Servers tried: [remote://localhost:4447 (Operation failed
with status WAITING after 5000 MILLISECONDS), remote://localhost2:4321
(Operation failed with status WAITING after 5000 MILLISECONDS)] [Root
exception is java.net.ConnectException: Operation failed with status
WAITING after 5000 MILLISECONDS]

Quand un des serveurs disponibles répond, mais que l'authentification qui suit échoue, l'exception AuthenticationException sera lancée :
javax.naming.AuthenticationException: Failed to connect to
any server. Servers tried: [remote://localhost:4447 (Authentication
failed: all available authentication mechanisms failed),
remote://localhost2:4321 (Operation failed with status WAITING after
5000 MILLISECONDS)] [Root exception is
javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed]

Un message approprié s'en suivra pour les échecs en connexion à chaque serveur de la liste.
1061609 - InitialContext avale la cause de l'exception d'origine

Dans les versions précédentes d'EAP 6, l'installation d'InitialContext peut échouer accompagnée du message suivant :
javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "deployment.externalContextBindingTest.jar:main" from Service Module Loader

En lisant ce message, cependant, la cause sous-jacente n'était pas visible, ce qui rendait le dépannage impossible. Pour résoudre ce problème, la cause sous-jacente a maintenant été exposée. Si ce problème se produit maintenant, le message d'erreur révèle maintenant la cause principale :
javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "deployment.externalContextBindingTest.jar:main" from Service Module Loader [Root exception is javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]]
1059836 - Une exception de communication de nommage à distance doit être lancée sur ConnectException

Dans les versions précédentes de JBoss EAP, une exception générique javax.naming.NamingException était levée lorsqu'une java.net.ConnectException se produisait à la place de javax.naming.CommunicationException plus spécifique.

Cette version inclut un changement qui garantit que javax.naming.CommunicationException soit envoyée quand une exception de connexion a lieu.

CommunicationException est une sous-classe de NamingException, donc tout code qui interceptait NamingException auparavant fonctionne toujours comme prévu.

Autre

901210 - Répertoires de déploiement du nettoyage - AS7-6031

Cette version de JBoss EAP 6.3 inclut un correctif qui veille à ce que les fichiers et répertoires créés dans les dossiers JBOSS_HOME/tmp et JBOSS_HOME/tmp/vfs soient supprimés avant qu'ils puissent interférer avec des instances EAP nouvellement (re)démarrées.

Dans les versions précédentes de JBoss EAP, les fichiers plus anciens auraient pu a voir été laissés en arrière après qu'un serveur se soit fermé inopinément (car JBoss EAP supprime les fichiers de JBOSS_HOME/tmp et de JBOSS_HOME/tmp/vfs dans le cadre du processus de fermeture).

Dans cette version, le correctif fournit une sécurité intégrée afin de mitiger ce scénario. Si un serveur JBoss EAP 6.3 ne se ferme pas correctement, le serveur n'a pas l'occasion de nettoyer ces fichiers temporaires. Lors du redémarrage, toutefois, le serveur vérifie maintenant les emplacements ci-dessus et, si des fichiers d'une instance précédente sont présents, cela enclenche un processus de renommage/suppression qui permet la création de nouveaux fichiers pour la nouvelle instance (les vieux répertoires sont renommés afin d'éviter les interférences avec les fichiers nouvellement créés). Ces processus se produisent en parallèle.

Au moment du redémarrage de JBoss EAP (gracieusement ou autrement) les anciens fichiers temporaires sont maintenant supprimés (soit à l'arrêt ou au redémarrage), pour veiller à ce qu'ils ne prennent pas d'espace disque inutilement.

NOTELes utilisateurs doivent éviter d'utiliser le -Xrs JAVA_OPT car cela peut limiter le traitement des signaux et peut se traduire par une augmentation de la taille des répertoires tmp/vfs.

Correctifs

1110117 - Les demandes de correctifs de MBeans en cours de fermeture résultent en exception IllegalStateException

Dans cette version de JBoss EAP 6, le sous-système de correctifs PatchResource, malgré qu'il n'ait aucune dépendance par rapport à InstallationManagerService, peut tenter de l'utiliser quand il est fermé

Cela pouvait provoquer l'exception IllegalStateException si un hook de fermeture tentait d'interroger le sous-système de correctifs de MBeans.

Ce problème devra être résolu dans une version à venir.
1108952 - OutOfMemoryError dans les correctifs de grande taille

Dans les anciennes versions de JBoss EAP 6, les données de pièces jointes passées des contrôleurs hôtes maîtres à esclaves étaient lues entièrement en mémoire.

En conséquence, lors de l'installation de correctifs de grande taille, une exception OutOfMemoryError pouvait se produire sur des contrôleurs hôtes enfants. Cela pouvait se produire lors de l'installation du CP04 via le contrôleur de domaine avec les paramètres par défaut de la mémoire.

Dans cette version du produit, les pièces jointes sont enregistrées dans des fichiers temporaires, afin de ne pas consommer un montant excessif de mémoire et OutOfMemoryErrors n'a pas lieu sur des contrôleurs hôtes enfants.

PicketLink

1084596 - Backport PLINK-396

Dans les anciennes versions de JBoss EAP 6, il a été constaté que IDPWebBrowserSSOValve et IDPFilter de PicketLink décodaient le relaystate, à l'encontre de la spécification SAML. Ce problème a été résolu dans cette version du produit.

RESTEasy

1037753 - La variante choisie n'est pas toujours la plus adaptée

Dans les versions précédentes de JBoss EAP 6, il a été constaté que RESTEasy, tout en respectant les spécifications RFC 2616, ne retournait pas toujours le gestionnaire de média le plus approprié dans les cas où les facteurs de qualité étaient égaux mais que la spécificité était différente.

Par exemple, quand un En-tête d'acceptation de application/json, */* et que les valeurs de variante de ["application/xml","application/json"], Request.selectVariant() de RESTEASY choisissaient application/xml à la place de application/json.

Dans cette version, des valeurs d'en-tête d'acceptation spécifiques ont la priorité sur les variantes correspondantes moins spécifiques ayant la même valeur (si elles ont toutes deux q=1.0 ou q=0.5 par exemple).
1014393 - Stream fermait l'exception dans resetStream d'IBM jdk 16, 17 dans RHEL 5, 6

Dans les anciennes versions de JBoss EAP 6, le xercesImpl fourni par IBM JDK 16, 17 entrait en conflit avec le unmarshaller jaxb utilisé par resteasy-jaxb-provider.

Cette question se posait également lorsque l'utilisateur utilisait directement le jar xercesImpl fourni par EAP 6.

Ces conflits résultaient en erreur java.io.IOException: Stream closed quand on utilisait IBM JDK 16, 17 ou xerces:xercesImpl:2.9.1-redhat-x (fourni par EAP 6) comme dépendance dans un projet resteasy basé 2.3.6.Final-redhat-x.

Ce problème a été résolu.

RPMs

1086157 - Erreur avec yum update iso ou httpd -manual dans RHEL6|RHEL5 Web Server

L'action yum update dans une nouvelle instance de JBoss EAP 6 en cours d'exécution sur Red Hat Enterprise Linux basé systèmes produisait, avant cette version, une erreur. C'était parce qu'il manquait une dépendance tr/min (httpd-manuel) dans le canal jbappplatform-6-i386-server-6-rpm. Le paquet httpd-manuel a maintenant été ajouté à la chaîne et l'exécution de yum update ne produit plus d'erreur.

Remoting

1052204 - Incompatibilité de protocole entre les classes sérialisables ayant des superclasses différentes non sérialisables

Dans les versions précédentes de JBoss EAP 6, une exception était lancée quand les JVM d'IBM et d'Oracle communiquaient en sérialisant une classe StringBuilder ou StringBuffer.

Cela était dû au protocole de marshalling qui sérialisait par erreur un descripteur de classe pour la première superclasse non sérialisable d'une classe sérialisable.

Ce problème a été résolu dans cette version du produit par une mise à niveau du composant JBoss Marshalling.
1102271 - JBoss Marshalling ne doit pas exiger de classes pour les champs null

Dans les versions précédentes de Red Hat JBoss EAP 6, si un objet contenait un champ dont la valeur était nulle et que le type d'objet du champ n'existait pas côté unmarshalling, les tentatives d'unmarshalling de l'objet échouaient en générant une exception ClassNotFoundException pour le champ.

Le problème a été corrigé dans cette version du produit.
1069075 - Fuite de chaîne et OutOfMemoryError dans Tomcat avec jboss-client.jar, en appelant un EJB dans EAP

Une mise à niveau du composant Remoting JBoss dans JBoss EAP 6 a résolu un problème OutOfMemoryError trouvé dans les versions antérieures du produit. La question a été retracée à des fuites de chaînes qui se produisaient lorsqu'une application Web appelait un EJB sur Tomcat.
1011831 - JBREM000205: N'a pas pu accepter une connexion : java.nio.channels.ClosedChannelException lors de la fermeture du serveur.

Un message DEBUG du sous-système distant était journalisé en tant que WARN par erreur au moment de la fermeture du serveur. Le message journalisé ressemblait à ceci :
02:46:15,512 WARN [org.jboss.remoting.remote] (Remoting "node1:MANAGEMENT" read-1) JBREM000205: Failed to accept a connection: java.nio.channels.ClosedChannelException

Dans le cadre d'une mise à niveau du sous-système de communication à distance de cette version de JBoss EAP 6, ce message a été correctement reclassé comme un message de niveau DEBUG.
1080429 - Changer JBREM000200 de ERROR à DEBUG puisque c'est sans conséquence

Les utilisateurs des versions précédentes de JBoss EAP 6 sur les plates-formes Windows ont peut-être rencontré la IOException suivante lors de la fermeture de la connexion JMX :
JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host

Cette erreur était provoquée par Windows qui fermait des connexions par la force. Comme cela n'avait aucun effet adverse, le niveau de journalisation de l'erreur passait à DEBUG, pour éviter qu'elle figure dans les journaux de niveau inférieur.
1052258 - faute de segmentation et autres problèmes xnio sur IBM JDK d'IBM-I

On a corrigé un problème concernant des applications exécutant sur les systèmes IBM qui échouaient avec une faute de segmentation qui a été corrigée dans cette version de JBoss EAP 6.

Les accidents étaient causés par des implémentations NIO dans les JDK IBM qui sont optimisés pour une utilisation sur des systèmes d'exploitation IBM. La couche I/O de JBoss EAP tente de détecter et d'utiliser ces implémentations. Cependant, sur certains systèmes d'exploitation (comme IBM-je), ces implémentations provoquent une erreur de segmentation.

Dans cette version du produit, ces systèmes d'exploitation sont détectés et on utilise des recours autonomes. Cela résout le problème d'erreur de segmentation et le serveur d'applications ne se bloque plus de manière inattendue.

Remoting, Web

1032552 - Erreur OOM à cause du grand nombre d'objets org.apache.tomcat.util.net.JIoEndpoint$Poller

Une fuite de chaîne pouvant résulter en une exception OutOfMemoryError a été corrigée dans cette version de JBoss EAP 6. La fuite a été attribuée à la classe JIoEndpoint. Le code correspondant a été corrigé et l'erreur OOM n'est plus présente.

Scripts et Commandes

1062595 - RuntimeException par utilitaire add-user une fois que le nom de l'utilisateur correspond au mot de passe (mode non interactif)

Les versions précédentes de JBoss EAP 6 lançaient une RuntimeException en cas d'échec d'un appel non interactif à l'utilitaire add-user (comme cela arrive avec des combinaisons de nom d'utilisateur/mot de passe problématiques). Cette exception visait à alerter les scripts d'une défaillance. Les exceptions pouvaient toutefois être confondues avec un bogue puisque ces types d'exceptions ne devaient pas être propagés sans handling. Une exception personnalisée a été ajoutée à cette version du produit pour indiquer que l'affichage est intentionnel et non pas révélateur d'un bogue de l'utilitaire add-user.
1027165 - add-user.sh nécessite une sortie de console

Dans les versions précédentes de JBoss EAP 6, le script de shell permettant d'ajouter des utilisateurs à un serveur EAP (add-user.sh) ne pouvait pas être exécuté sans la console (mode non interactif).

C'est parce que le script de shell (add-user.sh) s'appuie sur la console (java.io.Console) pour les opérations.

L'exécution du script de shell (add-user.sh) résultait en l'exception suivante, ainsi qu'en la cessation de l'emploi de l'utilitaire au final :
java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.

Ce problème a été résolu dans cette version du produit.
1063888 - Le script add-user affiche des informations de mot de passe incorrectes pour l'argument help (d'assistance)

Dans les versions précédentes de JBoss EAP 6, la sortie help de l'utilitaire add-user affichait uniquement une restriction pour les mots de passe (qu'ils ne correspondent pas au nom d'utilisateur). Cela pouvait prêter à confusion lors de l'ajout de nouveaux utilisateurs, car il y a plus d'une restriction en place pour s'assurer que des mots de passe valides sont utilisés. Dans cette version du produit, l'unique restriction a été supprimée du texte d'assisance (help text). Cela apparaît maintenant, au côté d'autres restrictions applicables, dans les messages qui s'affichent lorsque vous utilisez le mode interactif.
1062611 - add-user: '@' n'est pas parmi les caractères non-alphanumériques pendant la validation du nom d'utilisateur

Dans les versions précédentes de JBoss EAP 6, l'utilitaire add-user affichait un message d'erreur erroné lorsqu'un nom d'utilisateur non valide était spécifié. Le message déclarait qu'un nom d'utilisateur devait être alphanumérique, alors qu'en fait, l'utilitaire avait été modifié pour accepter un sous-ensemble de symboles spéciaux dans les noms d'utilisateur. Le message d'erreur a été reconstruit afin de pouvoir contenir la liste des symboles acceptables et les utilisateurs peuvent maintenant voir un message d'erreur plus précis lorsqu'un nom d'utilisateur invalide est saisi.
1020677 - Le script de service de mode domaine utilise une chaîne erronée pour vérifier si JBoss a démarré

Dans les versions précédentes de JBoss EAP 6, il a été constaté que les scripts de service de domaine ou autonomes utilisaient une variable incorrecte pour déterminer si le serveur a démarré correctement.

Cela pouvait conduire à des résultats erronés lorsque vous essayiez de vérifier l'état du serveur.

Ce problème a été résolu dans cette version.
956281 - Démarrer EAP 6.1 dans windows avec une jvm 32bit peut se traduire par un échec du démarrage de la JVM

Lorsque vous exécutez des anciennes versions de JBoss EAP 6 sur des JVM 32-bit de Windows 8, le paramètre définissant « max perm gen space » empêchait la création de la JVM, ce qui empêchait ensuite le serveur de démarrer.

Ce problème a été résolu dans cette version.
1057127 - jconsole ne fonctionne pas quand un correctif met à jour certaines de ses dépendances

Les anciennes versions de JBoss EAP 6 contenaient un bug qui empêchait le script jconsole.sh d'exécuter à chaque fois qu'un correctif CP1 était appliqué. Le correctif mettait à jour certains modules codés en dur dans jconsole.sh qui, à son tour, falsifiait les fichiers jar du module d'origine.

Ainsi, il n'était pas possible de se connecter à une console EAP par jconsole.sh.

Les problèmes ont été résolus en utilisant le jboss-cli-client.jar de bin/client, qui contient toutes les dépendances requises.
1062592 - Message d'erreur erroné en provenance de l'utilitaire add-user

Un message d'erreur donné par l'utilitaire CLI add-user a été modifié dans cette version de JBoss EAP 6 pour éviter toute confusion.

Dans les versions précédentes du produit, un message d'erreur indiquant que les mots de passe d'utilisateur devaient contenir au moins un caractère alphanumérique apparaîssait si le mot de passe entré contenait uniquement des caractères numériques. Dans cette version, le message d'erreur indique désormais que les mots de passes composés de caractères numériques doivent contenir au moins un caractère alphabétique.
1057625 - solution cygwin de syntaxe pour le script add-user.sh(EAP 6.3.0)

Dans les versions précédentes de JBoss EAP 6, il a été constaté que le script add-user.sh échouait lorsqu'il était exécuté dans des environnements Cygwin.

Une ligne de code de script mal mise en forme en était la cause.

Ce problème a été résolu dans cette version, mais le script exécuté dans des environnements Cygwin contient encore une question non résolue. Reportez-vous au ticket 1069252 dans la section Problèmes connus de ce document pour plus d'informations.
928486 - Les exigences de mot de passe doivent s'afficher immédiatement

Dans les versions précédentes de JBoss EAP 6, un utilisateur qui avait saisi un mot de passe non valide avec l'utilitaire add-user recevait seulement une erreur pour la première contravention aux règles de mot de passe notée.

Si l'utilisateur avait enfreind plusieurs règles, il lui fallait plusieurs tentatives de création du mot de passe avant qu'un mot de passe valide puisse être choisi.

Dans cette version, l'utilitaire de mot de passe affiche maintenant une liste complète des restrictions de mot de passe à l'avance, réduisant les chances de tentatives de mot de passe erronées.

Sécurité

1023084 - Bogue dans JBossJSSESecurityDomain.java - tentative d'utilisation du mauvais fournisseur

Dans les anciennes versions de JBoss EAP 6, JBossJSSESecurityDomain.java essayait d'utiliser le fournisseur de fichier de clés/truststore pour obtenir des instances du trust manager. Ce comportement était erronée, car le paramètre « trust-manager-factory-provider » ne pouvait pas être utilisé dans la section JSSE d'un domaine de sécurité. Utiliser ce paramètre (même si correctement configuré) se traduisait par une exception lors du démarrage. Ce bogue a été résolu dans cette version, et le paramètre « trust-manager-factory-provider » peut maintenant être utilisé pour déterminer le trustManagerFactoryProvider.
1065476 - Le module de connexion AdvancedLdap login ne peut pas traiter un utilisateur comprenant une barre oblique dans l'uid

Dans les anciennes versions de JBoss EAP 6, les demandes d'authentification échouaient si l'UID de la demande contenait un caractère barre oblique (/). C'est parce que le module de connexion AdvancedLdap ne gérait pas les guillemets correctement. Dans cette version du produit, le module de connexion a été modifié afin de supprimer les guillemets sur le DN de l'utilisateur retourné avant de tenter une liaison.
1069127 - RBAC + LDAP ont besoin de fonctionner dans <local/>

Dans les versions précédentes de JBoss EAP, le chargement en groupe LDAP peut échouer si un utilisateur authentifié n'a pas pu être mappé à un compte LDAP. Ce problème peut survenir parce que le processus d'authentification qui utilise des domaines de sécurité négocie tout d'abord un mécanisme entre le client et le serveur, puis charge les informations de groupe pour l'utilisateur. Parce que le système d'authentification local représente l'utilisateur avec un nom d'utilisateur artificiel, la deuxième partie de ce processus peut échouer si le serveur LDAP ne peut pas mapper le nom d'utilisateur à un utilisateur.

Dans cette version du produit, un nouvel attribut; skip-group-loading, a été ajouté à l'élément <local/> utilisé pour l'authentification locale. Quand cet attribut est défini sur true, le chargement de groupe est ignoré après l'authentification locale, afin d'éviter l'erreur. Si un mécanisme différent est utilisé, alors le chargement du groupe se poursuit normalement.
1066488 - management security realm : les références LDAP ne fonctionnent pas

Dans les anciennes versions de JBoss EAP 6, un bogue stipulait que tous les utilisateurs et les groupes doivent être définis et consultables sur le même serveur LDAP.

Toutes les entrées utilisateur ou groupe qui aboutissent en une référence ne seront pas utilisables dans JBoss EAP 6.

C'était parce que la recherche LDAP dans les domaines de sécurité ne contenait aucune logique de gestion des références si on les rencontrait pendant l'authentification d'un utilisateur dans LDAP ou via le protocole LDAP pour charger leurs groupes.

Le problème a été corrigé dans cette version et les références LDAP fonctionnent maintenant correctement.
1030053 - NegotiationAuthenticator perd des post data

Dans les anciennes versions de JBoss EAP 6, il a été constaté que NegotiationAuthenticator perdait des paramètres SAMLRequest si il était utilisé en conjonction avec la liaison PicketLInk et HTTP_POST. Il en résultait que les utilisateurs étaient bloqués sur la page de lancement d'IDP, même après une authentification réussie. Le NegotiationAuthenticator a été corrigé dans cette version du produit et le problème n'a plus lieu.
1065486 - Le module de connexion LdapExtended ne peut pas traiter un utilisateur comprenant une barre oblique dans l'uid

Dans les anciennes versions de JBoss EAP 6, les demandes d'authentification échouaient si l'UID contenait un caractère barre oblique (/). C'est parce que le module de connexion LdapExtended ne gérait pas ce caractère correctement. Dans cette version du produit, le module de connexion a été mis à jour afin de supprimer les guillemets sur le DN de l'utilisateur retourné avant de tenter une liaison. Cela fixe le problème et les utilisateurs peuvent maintenant s'authentifier normalement.
974324 - La journalisation de la gestion en mode domaine EAP 6 est non existante

Dans les anciennes versions de JBoss EAP 6, la journalisation TRACE et DEBUG n'avaient pas été ajoutées aux interactions LDAP dans les domaines de sécurité. Cela rendait les diagnostiques de problème d'authentification très difficiles quand LDAP était utilisé car aucun enregistrement de débogage n'était disponible. La journalisation DEBUG a maintenant été ajoutée pour les domaines de sécurité où LDAP est utilisé. Les clients peuvent maintenant utiliser ces journaux pour diagnostiquer les questions sur LDAP des domaines de sécurité concernés.
1069885 - Les résultats de SecureIdentityLoginModule (et ConfiguredIdentityLoginModule) ne sont pas mis en cache par JAAS cache

Dans les anciennes versions de JBoss EAP 6, on rencontrait des problèmes de performance lors de l'utilisation du SecureIdentityLoginModule qui ne parvenait pas à mettre en cache les mots de passe cryptés de sources de données. Cela était causé par le fait que le cache JAAS ne permettait pas à la clé de cache d'avoir la valeur nulle lorsque l'application qui utilisait la source de données n'était pas sécurisée.

Dans cette version du produit, l'archivage de sécurité est utilisé pour encoder les mots de passe de base de données, sans se préoccuper du module de login JAAS, résolvant ainsi les problèmes de performance.
1067610 - Les tentatives d'authentification échoueront si le rolesQuery de DatabaseRolesMappingProvider renvoie un ensemble vide

Dans les versions précédentes de JBoss EAP 6, il a été constaté que les tentatives d'authentification échouaient quand DatabaseRolesMappingProvider renvoyait une valeur nulle. C'est parce que l'authentification n'était pas en mesure d'offrir des rôles aux utilisateurs authentifiés si la valeur était nulle. Dans cette version du produit, le système de sécurité va honorer les authentifications réussies et n'essaiera pas d'assigner des rôles dans les cas où la valeur retournée est nulle.
1000185 - La configuration auth-module JASPI ne prend pas en charge un attribut "module".

Dans les versions précédentes de JBoss EAP 6, la configuration auth-module JASPIC du sous-système de sécurité ignorait l'attribut "module". Cet attribut indique à PicketBox à partir d'où charger les classes auth-module personnalisées.

De ce fait, les auth-modules JASPIC personnalisés ne pouvaient pas être configurés car PicketBox ne pouvait pas déterminer le module jboss qui devait être utilisé.

Comme l'attribut de module existe déjà dans le schéma de sous-système de sécurité, le correctif exigeait l'ajout du code dans le sous-système de sécurité pour s'occuper de cet attribut, permettant ainsi à PicketBox de charger les modules personnalisés correctement.

Maintenant, les utilisateurs peuvent configurer les auth-modules JASPIC personnalisés en utilisant l'attribut "module" pour indiquer le jboss-module qui contient la classe de module personnalisée.

Serveur

955818 - les saisies de manifeste Class-Path de WARs-in-EAR non gérées correctement

Dans les versions précédentes de JBoss EAP 6, lorsque plusieurs sous-déploiements d'un EAR se référaient à un simple jar non-module par le biais de saisies de manifeste Class-Path, il était ajouté au chargeur de classe du premier sub-déploiement.

Cela entraînait des problèmes de chargement de classe car les classes de l'utility jar étaient placées dans le mauvais chargeur de classes.

Cette version du produit crée un nouveau module de déploiement pour l'utility jar, et tous les déploiements l'utilisent. Cela résoud le problème de chargement de classes.
1060269 - recherche inversée DNS sur contrôleur de domaines lorqu'il est chargé à nouveau

Les utilisateurs d'anciennes versions JBoss EAP 6 ont sans doute pu remarquer que les serveurs n'étaient pas en mesure de reconnecter le contrôleur de domaine une fois qu'il était chargé à nouveau quand les serveurs gérés n'étaient pas démarrés à nouveau également.

Ce problème surgissait si la recherche inversée d'IP n'était pas configurée correctement, ce qui signifie que les serveurs recevaient le nom d'hôte du contrôleur (et pas son adresse IP) pour se reconnecter. Dans ces situations, la connexion échouait.

Ce problème a été résolu dans cette version du produit en réutilisant les données stockées dans l'objet InetSocket. Ceci évite la nécessité de faire une recherche inversée d'IP et permet aux serveurs de se reconnecter comme prévu.
1036872 - Impossible de configurer un paramètre de fichier de stratégie de sécurité qui désactive les fichiers de stratégie spécifiés dans le fichier java.security de JRE

Un problème a été identifié en utilisant le préfixe spécial = pour désactiver les fichiers de stratégie par défaut. La cause sous-jacente est que, lorsque le contrôleur hôte démarrait un serveur, il donnait comme valeur null au paramètre java.security.policy, conduisant à l'utilisation des fichiers de stratégie spécifiés dans le fichier java.security et peut-être aussi à des échecs d'autorisation empêchant le démarrage du serveur.

Ce problème a été résolu en modifiant le traitement des propriétés système, afin que la valeur d'une propriété système dont la valeur commence par « = » ne soit plus redéfinie à null par le contrôleur hôte lors du démarrage d'un serveur.
1049999 - Class-Path: . peut causer JBAS011046: Un composant nommé 'TestBean' est déjà défini dans ce module

Dans les versions précédentes de JBoss EAP 6, certaines bibliothèques jar de WEB-INF/lib contiennent un manifeste avec un attribut Class-Path qui contenait "." comme entrée.

Ce problème faisait que certaines ressources ou composants étaient traités deux fois, causant des alertes de journalisation.

Cette version du produit ignore les entrées "." entrées dans Class-Path manifestent attributs donc les ressources ne sont plus traitées deux fois.
924562 - Le redémarrage du déploiement causé par le remplacement d'une dépendance ne fonctionne pas

Un problème qui pouvait entraîner une NullPointerException a été résolu dans cette version de JBoss EAP 6. L'exception se présentait parfois au redémarrage lorsqu'un déploiement qui redémarrait partiellement certaines structures de données qui étaient nécessaires avaient déjà été nettoyées pour conserver de la mémoire (par exemple, lorsqu'une dépendance était remplacée). Ce problème empêchait que redéploiement se conmplète. Pour résoudre ce problème, les redéploiements partiels ne sont plus autorisés dans cette version du produit. Si une dépendance est remplacée, le déploiement sera maintenant complètement redémarré et l'exception ne sera plus présente.

Transaction Manager

1038993 - Impossible de changer le type de magasin d'objets de hornetq à jdbc par les commandes cli

Dans les anciennes versions de JBoss EAP 6, les modifications apportées au type de magasin d'objets (de HornetQ à JDBC, ou vice versa) par le biais de l'interface CLI n'étaient pas diffusées correctement.

De ce fait, le magasin d'objets ne changeait pas (option non préférée)

Dans cette version, les handlers d'écriture use-hornetq-store et use-jdbc-store ont été améliorés pour désactiver l'autre option lorsqu'ils sont utilisés et que le magasin d'objets utilisé est toujours l'option choisie.
1034650 - Augmenter la valeur par défaut du com.arjuna.ats.jta.orphanSafetyInterval

Dans les anciennes versions de JBoss EAP, un problème qui parfois causait de nombreux rollback XAExceptions journalisées, quand une durée de traitement de transaction empiètait sur la durée de l'activité de la procédure de restauration périodique, a été corrigé dans cette version du produit. L'intervalle de délai d'attente de orphanSafetyInterval a été augmenté à 20 secondes, ce qui diminue de manière significative la possibilité de rencontrer les exceptions.
1027126 - Le serveur n'a pas démarré avec standalone-xts.xml et le magasin d'objets JDBC exécutant sur mysql 5.5

Dans les versions précédentes de JBoss EAP 6, lorsque le gestionnaire de transactions était configuré pour exécuter des transactions XTS, utiliser un magasin d'objets JDBC hébergé sur MySQL 5.5, et que le pilote était mis dans le répertoire de déploiement, le serveur ne pouvait pas démarrer.

Ce problème a été résolu dans cette version.
1107569 - Optimisation en Une-phase : XAException de XAResource avalée et l'invocaiton de bean un faux succès

Un bogue était présent dans les versions précédentes de JBoss EAP 6 empêchait les utilisateurs de voir une exception qui indiquait l'échec d'une validation à phase unique.

Le bogue avait lieu quand le gestionnaire de ressources pouvait faire échouer XAR::end mais réussissait avec XAR::rollback, ce qui signifie qu'aucune exception n'était signalée à l'utilisateur.

Cette version du produit envoie l'exception qui convient à l'utilisateur confirmant ainsi la valisation à phase unique.
1092198 - LogStoreProbeHandler remplace le modèle root LogStoreResource

Dans les anciennes versions de JBoss EAP 6, on a détecté que LogStoreProbeHandler remplaçait le délégué détenu par LogStoreResource. Cela supprimait toutes les données du champ modèle du délégué existant (comme par exemple, l'attrinut "type").

Ainsi, quand on invoquait l'opération probe sur subsystem=transactions/log-store=log-store, la valeur du type d'attribut de la ressource était changé à la valeur par défaut même si le gestionnaire de transactions utilisait hornetq. Le comportement d'exécution réel n'était pas affecté, mais la valeur rapportée apparaissait comme une erreur.

Dans cette version du produit, le contenu du modèle du délégué actuel est copié dans le nouveau délégué avant d'être supprimé et l'attribut type ne sera plus par défaut après avoir exécuté l'opération probe lorsque le type de magasin de journaux est en fait quelque chose d'autre.

Web

1027272 - ContextNotActiveException levée sur la validation de session lorsque vous utilisez cluster SSO

Dans les versions précédentes de JBoss EAP 6, les valves SSO ne définissaient pas le contexte si les sessions expirées étaient associées à SSO.

Cela impliquait que ClusteredSingleSignOn appelait WeldListener.sessionDestroyed(event) une fois que la session était détruite, résultant en l'exception ContextNotActiveException suite à l'invalidation de la session.

Dans cette version du produit, les valves SSO définissent maintenant le contexte lorsque les sessions expirant associées à SSO et que l'exception ContextNotActiveException est évitée suite à l'invalidation de la session
1050204 WAIT_FOR_BEFORE_START ne fonctionne pas pour les applications / context

Dans les anciennes versions de JBoss EAP, la propriété WAIT_FOR_BEFORE_START ne fonctionnait pas pour les applications de contexte racine. Si un utilisateur définissait WAIT_FOR_BEFORE_START sur / et déployait une application racine, les connecteurs ne démarraient pas comme prévu.

Ce problème a été résolu dans cette version. Quand on définit WAIT_FOR_BEFORE_START à / et que l'on déploie une application de contexte racine, les connecteurs démarrent bien.
1105160 - CPU élevé en accès concurrent à la mappe JSSESupport keySizeCache

Le keySizeCache de JSSESupport n'était pas synchronisé correctement dans les anciennes versions de JBoss EAP 6.

Pour cette raison, l'accès simultané au keySizeCache de JSSESupport pouvait résulter en un grand nombre de boucles de mappes de hachage de CPU.

Dans cette version, l'accès au keySizeCache de JSSESupport est synchronisé et l'accès à keySizeCache n'a pas lieu.
1036197 - Le connecteur HTTP Natif échoue si org.apache.tomcat.util.Constants.ENABLE_MODELER est défini à true

Dans les anciennes versions de JBoss EAP 6, les méthodes *Protocol classes start() construisaient un nom de MBean avec la valeur de getName(), susceptible de contenir un signe deux-points et le nom d'objet de MBean ne peut pas contenir deux points arbitraires.

Quand JBoss essaie de démarrer, l'erreur suivante était rapportée si -Dorg.apache.tomcat.util.Constants.ENABLE_MODELER=true était ainsi défini :
JBWEB003044: Threadpool JMX registration failed: javax.management.MalformedObjectNameException: Invalid character ':' in value part of property

Cette version utilise getJmxName() plutôt que getName() pour construire correctement le nom du MBean.

De ce fait, l'exception n'a plus lieu quand -Dorg.apache.tomcat.util.Constants.ENABLE_MODELER=true est utilisé, avec le modeleur actif.

Console web

1079948 - Impossible de voir tous les hôtes dans la console de gestion JBoss EAP 6.2

Dans les anciennes versions de JBoss EAP 6, le sélecteur d'hôtes avait une barre de défilement manquante. Cela rendait difficile la sélection les hôtes qui n'étaient pas visibles dans le sélecteur.

La barre de menu défilant a été ajoutée au sélecteur de l'hôte dans cette version du produit et tous les hôtes peuvent ainsi être sélectionnés facilement.
1014219 - RBAC: Visibilité d'élément de contrôle pour les utilisateurs ayant plusieurs scoped roles

Les utilisateurs à qui étaient alloués des rôles multiples voyaient dans la console des opérations auxquelles ils n'avaient pas accès. Par exemple, un utilisateur avec les rôles host-master-administrator et host-slave-monitor auraient seulement dû être en mesure de voir les éléments de contrôle (par exemple, le bouton Add dans la page de configuration du serveur) dans le contexte host slave. Ce bouton n'aurait pas dû être visible lors d'une utilisation en contexte host master (toutefois, c'était le cas).

Les opérations visibles qui n'auraient pas dû l'être échouaient si tentées, car le bon contrôle d'accès était appliqué dans l'exécution de l'opération. Il y n'avait aucune violation de sécurité.

Ce problème dans la console de gestion a été corrigé dans cette version. Les éléments de contrôle qui ne sont pas liés à un rôle d'utilisateur, et bien que visibles, ils sont grisées et ils ne sont pas actifs.
900849 - Erreur de CLI EAP6 quand les données dépassent 64k

Chaque commande CLI retournant une chaîne de plus de 65535 caractères de long échouait avec le message erreur suivant :
Communication error: java.util.concurrent.ExecutionException: Operation failed

Cela était dû à l'utilisation de la méthode java.io.DataOutput.writeUTF() dans la bibliothèque de JBoss DMR. Cette méthode lève une exception UTFDataFormatException si la chaîne en cours de traitement a plus de 65535 caractères de long. La bibliothèque JBoss DMR a été mise à jour pour utiliser une autre technique afin de traiter correctement les chaînes de cette longueur. Toute commande CLI qui retourne une chaîne de plus de 65535 caractères de long fonctionne comme prévu.
901227 - attributs node-timeout, worker-timeout, flush-wait et ttl mod_cluster dans la console web

Un problème présent dans une version précédente de la Console de gestion JBoss EAP 6 basée-web empêchant les utilisateurs d'afficher ou de définir une valeur de -1 pour les attributs répertoriés mod_cluster a été rectifié dans cette version :
  • node-timeout
  • worker-timeout
  • flush-wait
  • ttl
1103747 - Impossible de répertorier tous les Queues/Topics (dans l'onglet "Profiles") dans la Console de gesiton d'EAP 6.x

Dans les anciennes versions de JBoss EAP 6, les utilisateurs avaient remarqué qu'ils ne pouvaient pas énumérer tous les topics et/ou queues sous l'onglet Profils dans la Console de gestion. Le nombre maximal de files d'attente qui était visible était de huit. Cela a été abordé dans cette version et maintenant, toutes les files d'attente sont visibles.
1029687 - La déconnexion de la configuration de la console admin sécurisée (ssl) redirige vers les adresses http

Dans les versions précédentes de JBoss EAP 6, les utilisateurs qui se déconnectaient d'une console d'administration sécurisée (via HTTPS) étaient incorrectement réorientées vers des adresses HTTP standards et la déconnexion échouait.

C'est parce que les redirections étaient codées en dur pour utiliser les adresses HTTP.

Dans cette version du produit, les redirections ont été mises à jour pour prendre en compte le fait que l'utilisateur accède à l'interface via HTTP ou HTTPS et redirige comme il convient.
1048211 - Domaine de sécurité affichant la mauvaise stratégie de sécurité dans la console de gestion

Dans les anciennes versions de JBoss EAP 6, un bogue amenait le domaine de sécurité à afficher une stratégie de sécurité erronée.

Le mise à jour de la sélection a été réparée dans cette version, et maintenant, les informations sont mises à jour en fonction de la stratégie de sécurité sélectionnée.
999813 - L'opération [Usability] Cancel (Annulation) est ignorée quand on vide les paramètres de destination JMS dans la console de gestion

Dans JBoss EAP 6.1.0 et 6.1.1, avant de vider une destination JMS via la console de gestion web, une boîte de dialogue de confirmation s'affichait, réclamant la confirmation de l'action. Quelle que fût la réponse de l'utilisateur, la destination JMS était vidée. La cause de ce problème était que le résultat de l'invite de confirmation était ignoré. Ce problème est maintenant résolu et la destination JMS est vidée uniquement si la boîte de dialogue de confirmation a été fermée avec la réponse « OK ».
1012490 - Énumérer tous les noms JNDI de destinations de messagerie dans la page des paramètres de runtime

Dans les anciennes versions de JBoss EAP 6, on a constaté que la page Paramétres de runtime des destinations de messagerie (Runtime > JMS Destinations) ne donnait la liste que d'un seul nom JNDI assigné par destination JMS (Java Messaging Service). Les autres noms JNDI de destination JMS (Java Messaging Service) étaient insérés sous forme de points de suspension ("...").

Cela signifie que la liste complète des noms JNDI d'une destination JMS (Java Messaging Servicing) ne pouvaient être accessibles qu'en visitant la liste complète des destinations dans les profils EAP.

Dans cette version, la liste complète des noms JNDI pour toutes les destinations de Java Messaging Service (JMS) sont visibles dans la page Paramètres de Runtime pour les destinations de messagerie (Runtime > Destinations JMS) avec l'aide d'une info-bulle.

Si une liste de noms JNDI est trop longue, elle sera tronquée et les points de suspension s'afficheront mais l'info-bulle n'affiche la liste complète que lorsque la souris pointe une entrée de nom JNDI.
1073537 - Des tests de connexion DS sont requis pour passer à travers tous les serveurs

Dans les anciennes versions de JBoss EAP 6, le test de connexion DS utilisait tous les serveurs du domaine. Cela pouvait impacter négativement sur la performance.

Dans cette version du produit, seuls les serveurs des profils actuellement sélectionnés sont utilisés pour le test de connexion, résultant ainsi en une meilleure performance.

Services web

1060001 - L'injection de dépendances Spring ne fonctionne pas sur les instances de points de terminaison

Un bogue présent dans les anciennes versions de JBoss EAP 6 empêchant les beans créés dans JBoss WS-CXF d'être injectés dans les points de terminaison a été réglé avec une mise à niveau du composant dans cette version.
1032593 - Les données sont gardées dans jboss-eap-6.2/standalone/data/wsdl après le retrait du déploiement de l'application

Les anciennes versions de JBoss EAP 6 stockaient des données dans le répertoire Web Services Description Language (WSDL) (EAP_HOME/standalone/data/WSDL) même après que le déploiement d'une application ait été annulé du serveur JBoss EAP.

Les données WSDL étaient stockées car c'était le comportement par défaut à chaque fois qu'une application était déployée sur le serveur sans mécanisme automatique de suppression des fichiers stockés.

Ce problème a été résolu par la mise à niveau des fichiers dans les référentiels (jbossws-cxf-4.2.x et trunk) pour modifier le comportement et publier les journaux WSDL.

Le correctif évite le stockage des données dans le répertoire WSDL quand un déploiement d'application est retiré d'un serveur JBoss EAP 6.3.
1032439 - échecs intermittents de testcases jbossws causés par javax.management.InstanceNotFoundException: jboss.ws:service=ServerConfig

Dans les anciennes versions de JBoss EAP 6, la configuration du serveur WS n'était pas toujours disponible via JMX.

Ceci était dû à l'obsolescence de la dépendance de service OPTIONAL du serveur MBean dans WS ServerConfigService

Dans cette version, la dépendance de serveur MBean est définie à REQUIRED et non pas à OPTIONAL quand le sous-système JMX est disponible

Ainsi, la configuration de serveur WS est toujours disponible via JMX quand le sous-système JMX est disponible
1069349 - Les importations de schémas dans CXF peuvent avoir des conflits de nommage dans les URL utilisés pour les extraire

Dans les anciennes versions de JBoss EAP 6, il y avait un bogue qui créait des conflits de nommage dans les URL quand on importait des schemas dans CXF. Ce problème a été résolu dans cette version du produit.
900634 - JBossWS-CXF n'envoie pas de message de faute à un point de terminaison FaultTo en cas de message requête-réponse.

Quand l'élément FaultTo de WS-Addressing était défini sur un client WS, le serveur WS ne renvoyait pas de messages d'erreur à la destination FaultTo. Toutefois, quand l'élément ReplyTo était défini, le serveur WS envoyait les réponses à la destination ResponseTo. Ce bogue a été corrigé dans cette version de JBoss EAP 6 avec une mise à jour d'Apache CXF.
1040732 - JAXBDataBinding ne peut pas gérer l'exception avec des objets génériques comme ObjectWithGenerics<Boolean, Integer>

Les versions précédentes de JBoss EAP 6 comportait un problème quand une classe Exception avait certains membres comportant des paramètres de type définis comme dans l'exemple suivant.

Le WSDL généré à partir de la classe exception était incorrect et on ne s'attendait pas au message d'erreur SOAP.
@javax.xml.ws.WebFault
public class GenericsException extends Exception {
  private static final long serialVersionUID = 1L;
  private ObjectWithGenerics<Boolean, Integer> obj;

  public ObjectWithGenerics<Boolean, Integer> getObj() {
  return obj;
  }
  public void setObj(ObjectWithGenerics<Boolean, Integer> obj) {
  this.obj = obj;
  }
}

Ce problème a été résolu en amont et le correctif incorporé dans cette version du produit.
1079084 - Webservices DUP ne scanne pas l'annotation @WebService pour toutes les classes visibles

On a découvert que le DUP Webservices des versions précédentes de JBoss EAP 6 copmportait un bogue qui empêchait le traitement de toutes les classes visibles avec l'annotation @WebService. L'erreur se présentait quand une archive war qui contenait un web.xml avec une <servlet-class> faisant référence à un point de terminaison JAX-WS (donc la classe était annotée avec @WebService) se trouvait dans une archive ear et le jar contenant la classe était situé dans le répertoire lib/ de l'archive ear. Le code correspondant a été modifié dans cette version pour pouvoir traiter plus précisément les classes de @WebService et l'erreur n'est plus présente.
1077259 - HttpServletRequestSnapshot n'est pas créé pour les demandes avec WSA ReplyTo activé.

Dans les versions précédentes de JBoss EAP 6, un bogue empêchait HttpServletRequestSnapshot d'être créé pour les requêtes avec WS-Addressing activé et la propriété d'en-tête ReplyTo spécifiée à une adresse non générique.

Ce bogue donnait lieu à une réponse HTTP 202 instantanée et à une demande de servlet recyclée rapidement par le conteneur. Cela empêchait les points de terminaison d'accéder à des informations de contexte pour la requête de servlet.

Ce problème a été résolu dans cette version du produit par une mise à niveau du composant CXF.
1079043 - MessageContext perdu quand le client JAX-WS est invoqué à partir d'une impl de point de terminaison JAX-WS

Dans les versions précédentes de JBoss EAP 6, lorsqu'un client JAX-WS était invoqué à l'intérieur d'un point de terminaison, le MessageContext du point de terminaison était retiré de ThreadLocal et non remplacé à la fin de l'appel du client.

Ce qui fait que le MessageContext n'était pas disponible pour les points de terminaison après une invocation JAX-WS.

Ce bogue a été résolu dans cette version du produit.
1031642 - La valeur false de l'attribut de sous-système de services web modify-wsdl-address est ignorée

Dans les anciennes versions de JBoss EAP 6, il y avait un bogue qui empêchait la pile WS de traiter @WebService(wsdlLocation=...) lors d'une réécriture wsdl soap:address.

L'attribut d'annotation ci-dessus n'a pas été traité lorsque l'annotation était placée sur les interfaces de point de terminaison de service uniquement.

Ce problème a été résolu dans cette version.
1060355 - Validation de schéma + Importations multiples de schémas dans le même espace-nom + Recherche Catalogue ne fonctionnent pas

Il y avait un problème qui empêchait org.apache.cxf.wsdl.EndpointReferenceUtils.SchemaLSResourceResolver#resolveResource de résoudre le schéma qui convennait et de retourner uniquement le premier schéma trouvé qui avait été corrigé par une mise à jour du composant CFX.

jbossas

1067620 - Impossible de modifier les permissions dans EAP 6 quand le Java Security Manager est actif

On a découvert un problème avec l'application Java Manager Security (JSM), où les applications déployées recevaient la permission AllPermission, ce qui contredisait le fichier de stratégie. La cause de ce problème est que le système de fichier virtuel (VFS) n'était pas activé, ce qui fait que la gestion des stratégies basées URL vfs: /... n'était pas chargée et les permissions par défaut étaient appliquées à la place. Ce problème a été résolu, en veillant à ce que le module VFS soit chargé afin que les stratégies JSM soient maintenant correctement appliquées.

mod_cluster

1008901 - Certains longs messages de journalisation n'ont pas d'id pour les identifier

Dans les anciennes versions de JBoss EAP 6, il y a deux messages de journalisation qui n'étaient pas localisés correctement.

De ce fait, les utilisateurs ne voyaient ni le message MODCLUSTER{id} ni la traduction.

Dans cette version, deux nouveaux messages ont été ajoutes : MODCLUSTER000044 et MODCLUSTER000045.

Les messages apparaissent maintenant comme prévus.
1030965 - Le nombre de contextes enregistrés ont un impact négatif sur la performance de mod_cluster

Un problème de performance a été identifié sur le serveur Apache HTTP avec mod_cluster configuré comme équilibreur de charge. Les opérations de mémoire httpd partagées sur la table workers->nodes affecte négativement la performance de l'équilibreur de charge. Ainsi, le rendement de l'équilibrage de charge httpd diminue au fur et à mesure que le nombre de contextes enregistrés augmente.

Une solution possible à ce problème consiste à diminuer le nombre de contextes enregistrés.

Pour résoudre ce bogue, le httpd a été modifié pour qu'il utilise la mémoire locale plutôt que la mémoire partagée.
1020142 - les XDS de sous-systèmes de modcluster ne décrivent pas l'attribut worker-timeout

Dans les versions précédentes de JBoss EAP 6, l'XSD mod_cluster utilisé pour les validations ne spécifiaient pas l'attribut worker-timeout.

Cela signifie que l'utilisation de XSD pour valider la configuration pouvait échouer même si la configuration était correcte et correctement interprétée par le serveur.

Le schéma XSD a été corrigé et utilise maintenant le schéma XSD pour validation quand l'attribut worker-timeout passe désormais la validation
1058334 - ${project.version} est maintenant résolu dans mod_cluster dans le journal du serveur

Dans les anciennes versions de JBoss EAP 6, la logique de chaîne de version utilisait ${project.version} dans le ModClusterLogger.java

De ce fait, ${project.version} était inscrit dans le journal du serveur.

Dans cette version, la logique a été corrigée, ajoutant une chaîne de version dans Version.properties et en la lisant avant de journaliser le message de démarrage. La version est maintenant correctement affichée dans le journal du serveur.
985101 - STOP-APP non inclus dans la page mod_cluster-manager avec ENABLE/DISABLE-APP

Dans les anciennes versions de JBoss EAP 6, la commande STOP-APP de la page du mod_cluster_manager n'apparaissait pas.

Le problème a été corrigé dans cette version et la commande STOP-APP est maintenant disponible dans la page mod_cluster-manager comme on peut s'y attendre.
980246 - mod_cluster-manager peut briser des alias à partir d'un simple hôte virtuel (VirtualHost), souillant ainsi une page

Dans les anciennes versions de JBoss EAP, il a été signalé que lors du déploiement d'applications multiples, chacune avec un serveur virtuel unique et chaque serveur virtuel avec plusieurs alias, le mod_cluster_manager pouvait afficher de manière incorrecte le même hôte virtuel plusieurs fois (une fois pour chaque alias).

Ce problème a maintenant été résolu et tous les hôtes virtuels ne sont affichés qu'une seule fois ensemble et avec tous les alias sur la page Manager.
1098576 - Les commandes stop de ModClusterService stop commands are always draining sessions

Dans les versions précédentes de JBoss EAP 6, quand on utilisait la commande stop stopContext ou ModClusterService de l'interface CLI, on ne parvenait pas à déplacer un contexte à l'état STOPPED une fois que les sessions actives sont purgées. Cela signifie que ces commandes n'étaient pas viables pour arrêter rapidement le contexte quand vous le souhaitiez (sans purge). Ce problème a été résolu avec une mise à jour pour le composant mod_cluster.
1044594 - [WFLY-2663] les propriétés de métrique de mod_cluster ne sont jamais appliquées

Dans les anciennes versions du mod_cluster, les métriques de chargement configurés du sous-système, et les propriétés spécifiées pour ces métriques étaient lus à partir de l'XML, mais n'étaient pas appliqués aux classes.

Cela signifie que les propriétés de configuration des métriques de chargement n'avaient aucun effet.

Dans cette version, les propriétés sont appliquées aux objets comme on s'y attend.
1052185 - MODCLUSTER-365: les MCMP redéfinis sont envoyés à tous les proxys disponibles

Dans une version antérieure de JBoss EAP, mod_cluster envoyait des MCMP (Mod_Cluster Manangement protocoles) sur tous les serveurs httpd dans sa liste de proxy quand l'un d'entre eux redémarrait. Ce comportement pouvait avoir un impact négatif sur les systèmes avec auto-enable défini sur false pour le contexte.

Le comportement attendu est d'envoyer la requête de reconfiguration uniquement au serveur redémarré. Ce problème avait lieu parce que DefaultMCMPHander.status appelait sendRequests qui, par défaut, envoie à tous les proxys.

Ce problème a été résolu par une mise à niveau du composant mod_cluster.