Serveur Apache et Connecteurs

mod_snmp et mod_rt sont maintenant disponibles via ppc64

À partir de JBoss EAP 6.4, mod_snmp et mod_rt sont disponibles sur les systémes Red Hat Enterprise Linux ppc64.

API

Activer la configuration du temps d'expiration de session globale du conteneur web par l'API de gestion

Le temps d'expiration de la session HHTP globale peut dorénavant être configurée par l'intermédiaire des API de gestion.

Exposer l'API publique pour les cas d'utilisation de Websockets.

Toutes les classes des packages javax.websocket et javax.websocket.server de l'API de Websockets API sont maintenant exposées publiquement.

Gestionnaire d'authentification

Une méthode logout() a été ajoutée à l'interface org.jboss.security.AuthenticationManager

Une méthode de logout à été ajoutée dans l'interface org.jboss.security.AuthenticationManager. Soyez en conscients si vous avez implémenté un org.jboss.security.ServerAuthenticationManager, comme dans l'exemple suivant.

<valve>
 <class-name>org.jboss.as.web.security.jaspi.WebJASPIAuthenticator</class-name>
 <param>
  <param-name>serverAuthenticationManagerClass</param-name>
  <param-value>com.acme.ServerAuthenticationManager</param-value>
 </param>
</valve>

Clustering

fail_on_status for mod_cluster

Un support pour fail_on_status a été ajouté au mod_cluster. fail_on_status peut être utilisé pour spécifier un ou plusieurs codes de statut HTTP, de façon à ce que si un noeud de worker d'un cluster renvoie un des codes de statut spécifiés, le worker échouera. L'équilibreur des charges enverra ensuite les futures requêtes vers un autre noeud de worker du cluster.

Gestion des domaines

Support des expressions imbriquées

Les expressions peuvent être imbriquées, ce qui permet une utilisation plus avancée des expressions au lieu de valeurs fixes. Les expressions imbriquées sont autorisées partout où elles sont autorisées, à l'exception des commandes CLI de gestion. En ce qui concerne les expressions normales, les sources prises en charge pour résoudre les expressions imbriquées sont : propriétés système, variables d'environnement et de l'archivage sécurisé.

Possibilité de lire les erreurs boot via les API d'admin

Une nouvelle commande de gestion CLI a été créée, qui renvoie les détails de toutes les erreurs qui se sont produites au démarrage. La commande est read-boot-errors et n'a aucun paramètre.

Autorisation Kerberos pour une gestion via HTTP/HTTPS

Il est maintenant possible de configurer l'authentification des opérations de gestion via HTTP/HTTPS en utilisant Kerberos. Cela signifie qu'il est maintenant possible d'authentifier la console de gestion en utilisant Kerberos.

EE

Possibilité de spécifier une référence d'adaptateur de ressource dans jboss-ejb3.xml sans le nom de l'ear

Dans le descripteur de déploiement de jboss-ejb3.xml, vous pouvez spécifier un adaptateur de ressources pour un MDB (message driven bean) à utiliser, sans spécifier le nom de l'EAR, quand le descripteur de déploiement est dans la même EAR que l'adaptateur de ressources.

EJB

Nouvelle implementation de StrictMaxPool

Le conflit au sein de la StrictMaxPool EJB a été éliminé en changeant la structure de données sous-jacente.

Possibilité d'ajouter des stores persistents alternatifs pour les horloges EJB non clusterisées

Les données d'horloges EJB peuvent maintenant être stockées dans une base de données et partagées entre les instances d'un serveur clusterisé. Les avantages de cette méthode incluent la compatibilité à la haute disponibilité.

Activer wilcard (*) pour <ejb-name> dans jboss-ejb3.xml

Support de l'utilisation des wildcards (*) activé pour <ejb-name> dans jboss-ejb3.xml.

Hibernate

Fournit un nouveau dialecte Hibernate Dialect pour MySQL 5.7

Un nouveau dialecte a été ajouté à Hibernate pour supporter MySQL 5,7. Pour éviter des problèmes liés à l'arrondissement des chiffres fractionnaires dans la date et l'heure, le dialecte présente actuellement les limitations suivantes : Hibernate assumera datetime(6) pour les colonnes « date de dernière modification » et time(0) pour les colonnes « heure ».

HornetQ

Possibilité de fermer tous les consommateurs sur une destination donnée et toutes les connexions pour ces consommateurs

La possibilité de fermer tous les consommateurs pour une destination donnée et les connexions pour ces consommateurs à été ajoutée. Cette commande est disponible via l'interface de gestion CLI, l'API de gestion et JMX.

« Abort » (abandon) ralentit les consommateurs de HornetQ

Le taux de consommation des consommateurs de messages peut désormais être surveillé automatiquement et des mesures prises si le taux ne remplit pas les critères spécifiques. Un taux de consommation minimale par seconde est spécifié dans les messages et s'il n'est pas respecté, soit la connexion du consommateur est supprimée ou une notification administrative est déclenchée, traitable par une application. Par défaut, cette fonctionnalité est désactivée.

Possibilité de terminer une connexion par un utilisateur JMS

HornetQ prend maintenant en charge la résiliation de connexions avec l'utilisateur JMS comme critère. Auparavant, il était seulement possible d'arrêter les connexions avec l'adresse IP client.

Hibernate Search

Fournir Hibernate Search en tant que module par défaut

Hibernate Search est maintenant un composant standard de JBoss EAP.

Le programme d'installation

Teste la source de données et les connexions LDAP dans le programme d'installation

Lors de l'installation de JBoss EAP en mode GUI ou console, le programme d'installation offre maintenant la possibilité de vérifier la connectivité LDAP et la source de données pendant le processus d'installation. Cela garantit que les paramètres fournis lors de l'installation sont valides

JBoss Web

Charge taglibs à partir de jars dans un JBoss Module

Les TDL (Tag Library Descriptors) peuvent être séparés de leurs applications respectives, ce qui facilite les additions et les mises à jour. Pour utiliser cette fonctionnalité, créer un moduler JBoss EAP 6 presonnalisé qui contient les JAR TLD, et qui déclare une dépendance sur ce module dans les applications.

Possibilité de configurer les cookies HttpOnly SSO

Un nouvel attribut a été ajouté à la configuraiton SSO d'une serveur virtuel : http-only. Si défini à true, cet attribut ajoute HttpOnly à l'en-tête du cookie, indiquant ainsi que le navigateur doive restreindre l'accès aux API non-HTTP.

Les utilisateurs doivent savoir que l'option de supporter cette restriction est entre les mains du client (le navigateur web).

Cette action may limite le risque de défaillances de sécurité en limitant l'accès aux API non-HTTP (comme JavaScript).

JCA

Support activé pour la propriété système "datasource_class"

Par défaut, quand une JAR de pilote de base de données contient un fichier services/javax.sql.Driver, l'attribut datasource_class de la définition de la source de données est ignoré et la classe du pilote de l'archive JAR est utilisée à la place. Pour supprimer ce comportement par défaut, et utiliser l'attribut datasource_class, définir la propriété à true -Dironjacamar.jdbc.prefer_datasource_class=true.

Détecte et envoie un exception de déploiement pour les adaptateurs de ressources JCA 1.7.

Une exception est envoyée si les déploiements JCA 1.7 sont détectés comme faisant partie d'une plateforme basée EE7.

Ajouter un pool de détecteurs de fuite

IronJacamar dispose désormais d'une implémentation de pool de connexion qui surveille les connexions et fournit une rétroaction si elles ne sont jamais libérées par l'application. Quand le pool est fermé ou vidé, une trace de la pile apparaît dans les journaux système. Pour activer le pool de connexions, définissez la valeur du système ironjacamar.mcp à org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool. Pour que la trace de la pile apparaisse sur un fichier séparé, définir la valeur de système de ironjacamar.leaklog au nom et au chemin d'accès du fichier voulu.

-Dironjacamar.mcp=org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool

-Dironjacamar.leaklog=leaks.txt

Opérations JMS

Ajouter l'opération remove-jndi pour les ressources JMS

L'opération remove-jndi est maintenant activée pour les ressources JMS.

JMX

Activer JMX MBean Registration et les notifications de désenregistrement des MBeans de façade de JBoss dans EAP 6.

Les MBeans qui se trouvent dans les domaines jboss.as et jboss.as.expr ne sont pas vraiment des MBeans mais sont des façades. De ce fait, l'enregistrement et le dés-enregistrement d'événements MBean a maintenant été établi pour ces domaines, ce qui permet à ces événements d'être surveillés.

Ouverture de session

Demander un support de suffixe pour la rotation de fichiers de journaux basée sur la taille.

La rotation de fichier journal basée sur la taille a été améliorée avec l'aide d'un suffixe d'horodatage qui est ajouté à chaque fichier journal après sa rotation. Le format de l'horodatage est configurable selon vos besoins. Auparavant, il n'était pas possible d'avoir un suffixe numérique ajouté aux fichiers journaux pivoté, rendant difficile la recherche de fichier journal particulier dans certaines circonstances

Implementer java.util.logging.LogManager.getLoggerNames() dans JBoss Logging

Une méthode getLoggerNames() a été ajoutée à java.util.logging.LogManager qui renvoie les noms de tous les enregistreurs d'événements

Le gestionnaire audit syslog devrait pouvoir se reconnecter automatiquement

Le gestionnaire audit syslog est maintenant amélioré grâce à un nouvel attribut - reconnect-timeout - qui spécifie le délai entre les tentatives de reconnexion au serveur syslog.

Rendez PeriodicSizeRotatingFileHandler configurable directement par la console CLI/web

Le PeriodicSizeRotatingFileHandler peut maintenant être configuré via la console de gestion ou l'interface CLI. Auparavant, un tel gestionnaire n'était capable d'être configuré en utilisant un gestionnaire personnalisé. Les nouvelles méthodes de configuration sont plus faciles et moins sujettes à l'erreur.

Masquer les propriétés système "password"

Toute propriété système qui contient le texte password (quel que soit le cas) est remplacée par le texte redacted quand il sort en journalisation. Cela améliore la sécurité en évitant d'avoir des mots de passe en texte brut dans les fichiers de journalisation.

Interface CLI

L'interface CLI prend en charge la substitution de noms d'éléments et pas uniquement pour les paramètres

La substitution des noms d'éléments a été ajoutée. Auparavant, l'interface CLI ne prenait en charge que la subsitution de propriété des paramètres.

Ajouter la commande echo pour la saisie de script par interface CLI

Une nouvelle commande de gestion CLI - echo - a été créée. Elle renvoie verbatim tout le texte qui suit la commande.

Console de gestion

Affiche les journaux de serveur dans la console graphique

Vous pouvez maintenant afficher des journaux de serveur et d'application dans la console de gestion JBoss EAP pour aider à diagnostiquer des erreurs, des problèmes de performance et d'autres questions. Pour être visible dans la visionneuse du journal de console de gestion d'un journal, elle doit se situer dans le répertoire du serveur jboss.server.log.dir. La visionneuse du journal respecte également les attributions de rôles d'utilisateur RBAC, donc un utilisateur connecté à la console de gestion ne peut voir que des journaux pour lesquels il a l'autorisation d'accès.

Le plugin Access Red Hat

L'accès aux fonctionnalités courantes du portail clients de Red Hat sont maintenant disponibles dans la console de gestion. La barre de navigation supérieure de la console de gestion contient un menu déroulant : Red Hat Access. En cliquant sur ce menu, vous apercevrez trois liens de tâche spécifique au portail client : Search Customer Portal, Open Case et Modify Case.

Expose le délai d'expiration de la session globale du conteneur web dans la console

Le délai d'expiration de la session globale HTTP peut maintenant être configuré par l'intermédiaire de la console de gestion.

Nommage

Utiliser le contexte externe pour la recherche TIBCO ems à distance

Lorsque vous utilisez l'adaptateur de ressources JMS générique pour vous connecter à un serveur de messagerie externe, un contexte externe peut être utilisé au lieu d'écrire un ObjectFactory personnalisé. Ce qui suit est un extrait d'exemple qui utilise <external-context>. Remplacer les propriétés de l'exemple par les propriétés appropriées pour votre fournisseur JMS.

<external-context name="java:global/tibco" module="com.tibco.tibjms" class="javax.naming.InitialContext">
 <environment>
  <property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
  <property name="java.naming.provider.url" value="TIBCO_EMS_SERVER_HOST_NAME:PORT"/>
  <property name="java.naming.factory.url.pkgs" value="com.tibco.tibjms.naming"/>
  <property name="org.jboss.as.naming.lookup.by.string" value="true"/>
 </environment>
</external-context>

Correctifs

L'accès aux détails de correctifs a été amélioré

La commande d'interface CLI patch possède deux arguments supplémentaires : inspect et info. Les informations de sortie de l'argument info sur les correctifs installés. Les informations de sortie d'argument inspect sur un correctif téléchargé.

Le panneau Patch Management (Gestion des correctifs) de la console de gestion a été amélioré pour inclure une brève description de chaque correctif et un lien vers un article plus détaillé.

Performance

Backport AbstractPool initLock() élimination de la synchronization de 1.2

Un verrou a été créé lors de l'appel d'enregistrement une transaction après avoir obtenu une connexion du pool. Étant donné que le registre de la transaction a déjà effectué le verrouillage, car il a déjà utilisé une collection simultanée, le verrouillage supplémentaire était donc inutile et a donc été supprimé.

Nouveau pool de connexions gérées

Un nouveau pool de connexions gérées dans le sous-système JCA a été créé, améliorant la performance et éliminant la contention de thread dans le serveur.

PicketLink

Plugin de console pour intégrer les sous-systèmes PicketLink dans la console EAP

Les sous-systèmes de PicketLink sont maintenant configurables par la console de gestion JBoss EAP, ce qui résulte en une meilleure configuration.

Modifier l'IDP PicketLink IDP pour qu'il prenne en charge les réponses SAML 2.0 non sollicitées

L'IDP (PicketLink Identity Provider) a été amélioré pour pouvoir envoyer dès maintenant des réponses SAML 2.0 non sollicitées au fournisseur de services.

PicketLink doit pouvoir être configuré de façon à pouvoir ignorer les appels ajax

Dans le cas où l'utilisateur n'est pas authentifié et envoie une requête à la fois à IDP et à SP en utilisant AJAX, PicketLink répond avec un code d'état HTTP 403 au lieu de présenter la page de connexion. Les requêtes AJAX sont identifiées en vérifiant la présence de l'en-tête X-Requested-With ayant pour valeur XMLHttpRequest.

RESTEasy

La journalisation RESTEasy par JBossLogging

Le fonctionnalité de journalisation RESTEasy est maintenant effectuée par JBossLogging. Les avantages de ce changement, c'est l'internationalisation des messages de journalisation.

Nouveaux paramètres de sécurité

RESTEasy a deux nouveaux paramètres qui doivent améliorer la sécurité lors du traitement des documents org.w3c.dom.Document. Ces deux paramètres sont des paramètres context-param et peuvent être mis dans le web.xml de l'application.

Le paramètre resteasy.document.secure.processing.feature impose des contraintes de sécurité lors du traitement des documents org.w3c.dom.Document et des représentations d'objet JAXB.

Le paramètre resteasy.document.secure.disableDTDs empêche les DTD dans les documents org.w3c.dom.Document et dans les représentations d'objet JABX.

La valeur par défaut de resteasy.document.secure.processing.feature et resteasy.document.secure.disableDTDs est true. Pour désactiver l'un ou l'autre, ou les deux, ajouter ce qui suit au fichier web.xml de l'application.

<context-param>
 <param-name>resteasy.document.secure.processing.feature</param-name>
 <param-value>false</param-value>
</context-param>
<context-param>
 <param-name>resteasy.document.secure.disableDTDs</param-name>
 <param-value>false</param-value>
</context-param>

Installation RPM et mises à jour

Il y a maintenant un choix de canaux de RPM ou de référentiels auxquels s'abonner pour l'installation et les mises à jour de JBoss EAP via RPM. Le canal actuel de JBoss EAP fournit la dernière version, et un canal mineur fournit une version mineure spécifique et tous les correctifs applicables. Cela permet de maintenir la même version mineure de JBoss EAP 6, tout en restant au fait des derniers correctifs de sécurité et les problèmes de haute sévérité. Pour plus de détails sur les canaux disponibles, consultez https://access.redhat.com/solutions/1346093.

Sécurité

SSLValve permet les noms d'en-tête configurables par les utilisateurs

Les noms d'en-têtes HTTP utilisés par SSLValve pour passer des informations SSL/TLS de l'auteur ont été prédéfinis, par exemple : ssl_client_cert, ssl_cipher, ssl_session_id et ssl_cipher_usekeysize. Avec ce changement, les noms des en-têtes sont maintenant personnalisables pour que l'expéditeur puisse utiliser un nom arbitraire de l'en-tête HTTP, avec le nom spécifié dans la configuration de SSLValve.

Authentification basée Kerberos pour les appels à distance

La prise en charge de l'authentification des EJB et des clients EJB est maintenant activée.

Les domaines de sécurité de gestion doivent mettre en cache les données LDAP

Le domaine de sécurité de gestion met les données LDAP en cache actuellement, ce qui aide à réduire le nombre de requêtes LDAP.

Autorisation avec des informations d'identification Kerberos statiques pour la source de données Oracle DB pour une JVM Oracle.

L'autorisation à l'aide d'informations d'identification Kerberos statiques a été ajoutée dans une source de données Oracle DB pour une JVM Oracle. Notez que cette version du pilote Oracle DB 11.2.0.3 ou plus récente est nécessaire, aussi le cache du domaine de sécurité doit être activé.

Autorisation avec des informations d'identification Kerberos statiques pour le serveur SQLServer pour une JVM Oracle.

Autorisation à l'aide des informations d'identification Kerberos statiques dans une source de données de serveur SQL Microsoft a été ajoutée. Notez que cette fonctionnalité est uniquement prise en charge pour les connexions non-XA.

Ajouter un support pour le mot de passe externe du keystore à l'implémentation PicketBoxVault

La fonctionnalité Vault prend maintenant en charge l'option d'avoir un mot de passe de keystore fourni par une commande externe ou une classe personnalisée.

Ajouter l'option "remove vault entry" (supprimer la saisie d'archivage de sécurité) à l'outil Vault

L'outil d'interface CLI Vault a été amélioré en ajoutant la possibilité de supprimer une valeur stockée dans un archivage sécurisé (vault).

Utiliser l'indicateur -secmgr pour la configuration d'un Java Security Manager

L'exécution de JBoss EAP dans le Java Security Manager est désormais activée, soit en ajoutant le paramètre -secmgr au script de startup ou en activant l'option SECMGR="true" dans le fichier de configuration. Activer le Java Security Manager par la propriété Java système -Djava.security.manager n'est plus possible. Suite à ce changement, les gestionnaires de sécurité personnalisés ne peuvent pas être utilisés. Démarrer JBoss EAP avec un gestionnaire de sécurité personnalisé activé résultera en une sortie de JBoss EAP avec un code non-zero exit au démarrage. Voir le Security Guide à propos des changements requis pour activer le Java Security Manager.

Configurations prises en charge

Oracle JDK 8

Oracle Java Platform, Standard Edition 1.8 (JDK 8) a été ajouté à la liste de configurations prises en charge.

IBM JDK 8

IBM JDK 8 a été ajouté à la liste de configurations prises en charge.

DBMS

Le DBMS suivant a été certifié et est maintenant totalement pris en charge :

• Enterprise DB Postgres Plus Advanced Server 9.3
• MySQL 5.7
• IBM DB2 10.5
• Microsoft SQL Server 2014
• PostgreSql 9.3

Fournit mod_snmp pour les versions RHEL testées sur PPC

Le module SNMP (Simple Network Management Protocol) mod_snmp est maintenant pris en charge pour l'architecture PowerPC64 exécutant Red Hat Enterprise Linux 6 et Red Hat Enterprise Linux 7.

WebSockets 1.0

Le protocole WebSocket 1.0 fournit la communication dans les deux sens entre les serveurs et les clients web. Les communications entre les clients et le serveur sont basées sur des événements, ce qui permet un traitement plus rapide et une plus petite bandwidth par rapport aux méthodes basées sur des interrogations.

L'application JBoss EAP 6.4 WebSocket fournit un support complet d'injection de dépendance des points de terminaison de serveur; cependant, elle ne fournit pas de services CDI pour les clients de points de terminaison. Le support CDI est limité à celui qui est exigé par la plate-forme EE 6, et de ce fait, les fonctionnalités EE7, telles les intercepteurs sur les points de terminaison, ne sont pas pris en charge.

L'installateur

BZ#1169462 - Installer should look automatically look for variables file during automated installs (le programme d'installation doit automatiquement chercher le fichier de variables pendant les installations automatiques)

Dans cette version de JBoss EAP 6.4, le programme d'installation cherche maintenant le fichier de variables automatiquement pendant l'installation.

Le programme d'installation cherche le fichier .variables uniquement si une installation automatisée est en cours et qu'aucune variable n'est passée à travers les balises -variables et -variablefile.

Le programme d'installation cherchera l'emplacement du fichier auto.xml pour commencer. S'il ne le trouve pas, il cherchera le répertoire de travail actuel de l'utilisateur.

Si l'utilisateur indique un fichier auto.xml distant, le programme d'installation cherchera le fichier .variables dans le répertoire de travail actuel de l'utilisateur.

Aussi, le fichier .variables ne sera détecté que s'il suit la convention de nommage suivante; <NAME_OF_AUTO.xml>.variable.

Transaction Manager

BZ#1168973 - JTS participants are not showing up in the tooling (les participants JTS n'apparaissent pas dans les outils )

Cette version de JBoss EAP 6 connaît une amélioration au niveau du composant Transaction Manager. Avant, tous les participants n'apparaissaient pas dans l'afficheur des journaux.

Maintenant, les types de participants suivants s'afficheront :

• AssumedCompleteHeuristicTransaction

• AssumedCompleteHeuristicServerTransaction

• AssumedCompleteTransaction

• AssumedCompleteServerTransaction

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1168973

WS-Trust/STS avec JBoss Web Services

JBoss Web Services montre maintenant les capacités de WS-Trust/STS à partir de l'implémentation CXF.

Apache CXF 2.7.13 change SAML/WS-Trust

Le service STS (Security Token Service) valide maintenant les tokens ActAs également, alors qu'il validait auparavant les tokens OnBehalfOf uniquement; ainsi, un nom d'utilisateur/mot de passe valide doit être donné dans le token de nom d'utilisateur (UsernameToken) fourni comme token ActAs.

Les tokens du porteur de tokens SAML doit maintenant avoir une signature interne; de plus le org.apache.ws.security.validate.SamlAssertionValidator contient une méthode setRequireBearerSignature pour activer/désactiver la vérification de cette signature.

Ajouter et supprimer les modules par JBoss CLI

L'interface en ligne de commande (CLI) propose de nouvelles commandes pour ajouter ou supprimer des modules.

Validation RestEasy par le validateur Hibernate

RestEasy inclut maintenant un fournisseur de validation qui supporte le validateur Hibernate fourni dans JBoss EAP 6.

Multi-JSF

Cette fonctionnalité permet à un utilisateur de remplacer l'implémentation JSF fournie dans JBoss EAP 6 par une implémentation JSF fournie par l'utilisateur.

mod_jk and IPv6

La version de mod_jk a été mise à jour. Cette nouvelle version contient un support pour IPv6, mais cette fonctionnalité n'a pas été entièrement testée.

Correctifs

BZ#1110117 - Querying patching MBeans during shutdown results in IllegalStateException (chercher à corriger des MBeans lors de la fermeture résulte en IllegalStateException)

Les tentatives d'interrogation d'un état de correctif d'une instance de JBoss EAP peuvent entraîner une exception IllegalStateException. La cause principale de cette erreur est que InstallationManagerService n'était pas disponible, car il est déjà fermé. Ce problème a maintenant été résolu en vérifiant d'abord si le InstallationManagerService est disponible et si tel est le cas, la requête peut se poursuivre.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1110117

EJB

BZ#1172856 - Server side EJB Handler not compression response (handler EJB côté serveur - pas de réponse de compression)

Quand on utilisait la compression dans les versions précédentes de JBoss EAP 6, le client envoyait un requête compressée, mais le serveur envoyait une réponse non compressée, même s'il était configuré pour renvoyer une réponse compressée.

Dans cette version, le serveur répondra par une réponse compressée comme il se doit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1172856

BZ#1118432 - java.util.concurrent.RejectedExecutionException if a remote-naming InitialContext should be closed (eception java.util.concurrent.RejectedExecutionException si un remote-naming InitialContext doit être fermé)

Si la distance de nommage est utilisée pour rechercher un EJB, cela crée un contexte ejb-client. Si l'objet de contexte d'attribution de noms distant a été fermé une fois effectué, le client journalisait l'erreur indiquée ci-dessous, parce que le contexte de l'ejb-client était déjà fermé alors qu'il tentait de le fermer à nouveau. La cause sous-jacente de cette erreur a été résolue en vérifiant le contexte de l'ejb-client avant de fermer.

ERROR [org.jboss.remoting.handler-errors] Close handler threw an exception: java.util.concurrent.RejectedExecutionException (fermeture du handler générant l'exception java.util.concurrent.RejectedExecutionException)

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1118432

BZ#1156620 - Memory leak on undeploy & too many channels caused by ejb client not disassociating (fuite de mémoire lors du retrait du déploiement causé par le client ejb ne se dissociant pas)

Cette version de JBoss EAP 6 corrige une fuite de mémoire causée par une application déployée qui utilise jboss-ejb-client.xml pour configurer les connexions clients EBJ à distance.

Ce correctif résout également le problème du contexte scoped qui était utilisé avec un trop grand nombre de canaux (car les canaux n'étaient pas fermés tant que tous les canaux d'un hôte donné n'étaient pas fermés). Le canal est maintenant fermé quand Context.close() est appelé, même si les autres canaux sont ouverts au même hôte.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1156620

BZ#1088463 - If large parameters are given to an EJB method invocation the client show a EJBCLIENT000032 Exception - the OutOfMemoryError is swallowed (quand des grands paramètres sont donnés à une invocation de méthode EJB, le client reçoit une exception EJBCLIENT000032 - et le OutOfMemoryError est absorbé

Dans la version précédente de JBoss EAP 6, lorsqu'une valeur élevée était passée à un paramètre pour l'appel de l'EJB, le canal s'écrasait et la sortie d'erreur de mémoire n'apparaissait pas sur le serveur. Avec l'ejb-client, une exception, il y a une exception qui indique que l'erreur survenait pendant l'unmarshalling de certains paramètres avec possibilité d'insuffisance de mémoire. Ce problème est maintenant résolu dans la version actuelle de JBoss EAP 6. Lorsqu'une valeur élevée est passée à un paramètre pour l'appel de l'EJB, une sortie d'exception mémoire insuffisante s'affiche sur le serveur et une indication s'affiche côté client.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1088463

CDI/Weld

BZ#1159570 - sujet injecté CDI ne fonctionne pas

Dans les versions précédentes de JBoss EAP 6, l'injection d'un Sujet JMS dans un bean CDI échouait avec l'erreur suivante :

javax.jms.InvalidDestinationException: Not a HornetQ Destination:HornetQTopic[EventTopic]

   @javax.inject.Inject 
   private javax.jms.Topic topic

Dans cette version, l'injection réussit sans erreur.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1159570

BZ#1166133 - Bean proxy class has non-varargs method for original varargs method (la classe du proxy de bean possède une méthode non-varargs pour la méthode varargs d'origine)

Dans les versions précédentes d'EAP, les méthodes varargs n'étaient pas correctement représentées dans les proxys de bean comme méthodes non-varargs avec un argument de tableau. Cela entraînait des problèmes de framework dépendant de la réflection.

Ce problème a été résolu en ajoutant l'indicateur vararg manquant dans le bytecode de la méthode proxy. De ce fait, les méthodes varargs sont maintenant représentées correctement dans les proxies de bean.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1166133

BZ#1146853 - Proxy naming conflict when using static nested classes with the same name and package (conflit de nommage de proxy quand on utilise des classes imbriquées avec le même nom et le même package)

Dans les versions précédentes d'EAP, si deux classes statiques imbriquées ayant le même nom et encadrées de classes différentes étaient utilisées en tant que beans, Weld générait des proxys ayant le même nom de classe pour les deux beans et l'exception ClassCastException était lancée quand ces beans étaient utilisés.

Ceci a été corrigé en modifiant la procédure de génération de nom de classe proxy pour inclure le nom de la classe englobante. Deux classes statiques imbriquées peuvent maintenant avoir le même nom de classe simple même si elles sont encadrées de deux classes différentes dans un même package.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1146853

BZ#1054876 - Proxy creation fails when a superclass does not have a no-arg constructor (la création de proxy échoue quand une superclasse ne possède pas de contructeur no-arg)

Les versions précédentes de JBoss EAP incluaient une implémentation de Weld qui contrôlait de manière stricte non justifiée que les constructeurs de toutes les superclasses aient des constructeurs no-arg publics.

Ce problème a été adressé dans cette version. Dorénavant, on ne vérifie plus que la possibilité de créer un proxy pour le bean lui-même, et non pas tous les supertypes.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1054876

BZ#1149644 - CDI Interceptor cannot inject EJB session context. (l'intercepteur CDI ne peut pas injecter le contexte de session EJB)

Dans les versions précédentes de JBoss EAP, il y avait une omission dans le code d'integration de Weld, ce qui fait qu'il n'était pas possible d'injecter un contexte de session EJB dans l'intercepteur CDI.

Cela a été réglé dans le code d'intégration en donnant l'emplacement exact JNDI EJBContext des points d'injection pour tous les contextes EJB.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1149644

BZ#1138192 - Package-private members not working on CDI beans in static modules (membres de package privés ne fonctionnant pas sur les beans CDI de modules statiques)_

Dans les versions précédentes de JBoss EAP, il y avait une optimisation du chargement de classes dans le code d'intégration Weld qui entraînait l'exception IllegalAccessException quand un bean normal-scoped de module statique qui déclarait un constructeur de package-private non-arg était injecté dans un bean d'un déploiement.

Cela a été réglé en limitant l'optimisation et en utilisant un chargeur de classes de module statique pour les proxys de classes originant du module statique donné.

L'exception IllegalAccessException n'est plus lancée pour les beans ayant des constructeurs package-private dans des modules statiques.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1138192

BZ#1086555 - Weld - Specialization of generic beans throws inappropriate exception (Weld - Specialisation des beans standards envoie une exception non appropriée)

Dans les versions précédentes de JBoss EAP 6, définir une specialisation sur un bean générique résultait en exception DefinitionException.

Ce comportement n'était pas voulu ainsi. Définir une spécialisation de bean standard fonctionne maintenant comme on s'y attend.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1086555

Gestion des domaines

BZ#1111575 - subnet-match is does not respect 'value' attribute (subnet-match ne respectant pas l'attribut 'valeur')

Les versions précédentes de JBoss EAP 6 contiennent un bogue qui empêchait subnet-match de respecter l'attribut value.

Dans cette version du produit, le problème a été résolu et l'attribut value fonctionne de la manière dont on s'y attend.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1111575

BZ#1159709 - IO error during deployment scanning triggers undeployment (une errreur IO en cours de lecture de déploiement déclenche le retrait du développement)

Dans les versions précédentes de JBoss EAP 6, la méthode FileSystemDeploymentService.scanDirectory() traitait la valeur retour « null » de File.listFiles() en tant que liste vide et non pas en tant qu'erreur.

De ce fait. les erreurs IO qui ont pu avoir lieu lors de la lecture du déploiement pouvaient déclencher le retrait d'un déploiement d'application.

Ce problème a été adressé et dans cette version du produit, les applications déployées ne sont plus retirées si la limite du fichier a été atteinte.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1159709

BZ#1133328 - Runtime updates to outbound LDAP connections not performed on host controller. (les mises à jour du runtime des connexions LDAP sortantes ne s'effectuent pas dans le contrôleur hôte)

Les handlers d'opérations de gestion de JBoss EAP 6 peuvent spécifier si une mise à jour de runtime doit être effectuée à la suite d'une mise à jour du modèle. Dans les versions précédentes, le handler de l'opération ne demandait des mises à jour que pour les définitions de connexion LDAP sortantes lorsqu'elles exécutaient dans un processus de serveur.

De ce fait, les changements qui ont été effectués sur les connexions LDAP sortantes dans un processus de contrôleur hôte ne menaient pas immédiatement à des mises à jour de runtime pour ce processus.

Dans cette version du produit, les opérations affectées exigent que les mises à jour de runtime s'appliquent à tous les types de processus et aux modifications apportées aux connexions LDAP sortantes et qu'elles soient immédiatement répercutées pour les processus de serveur d'application et sur les processus de serveur non liés à des applications.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1133328

BZ#1148565 - Management HTTP server closing idle connections prematurely. (serveur HTTP de gestion fermant les connexions inactives prématurément)

Le serveur HTTP de gestion de JBoss EAP contient un handler de timeout qui doit fermer les connexions inactives au bout de 5 minutes.

Dans les versions précédentes du produit, le délai d'attente mettait fin aux connexions après 30 secondes. Toute session SSL active était également résiliée suite à la fermeture de la connexion. Lorsque le navigateur du client web reconnectait pour un appel ultérieur, une nouvelle session SSL devait être créée.

Dans cette version du produit, le délai d'expiration de la connexion inactive est maintenant défini à 5 minutes comme il se doit.

Le navigateur Web initiant la fermeture des connexions actives fonctionne maintenant comme prévu, laissant toute session SSL sous-jacent intacte et permettant au navigateur web de reprendre sa session précédente, la prochaine fois qu'il se connecte.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1148565

BZ#1106393 - Managed server shutdown unexpectedly when timeout during connection request to HC (le serveur géré se fermait de façon inattendue lors des requêtes de connexion vers HC)

Dans les versions précédentes de JBoss EAP 6, une fois qu'une connexion de serveur géré à son controleur hôte échouait, une seule nouvelle tentative de connexion était possible.

Cela pouvait entraîner la fermeture soudaine du produit si la nouvelle tentative de connexion échouait.

Dans cette version, les connexions au contrôleur hôte sont tentées indéfiniement. Les instances de serveur ne se ferment plus à cause de la perte de connexion au contrôleur hôte.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1106393

BZ#1105677 - Nonexistent ldap group causes authentication to fail in security-realm (groupe ldap non existant entraîne un échec d'authentification de security-realm)

Dans la version précédente de JBoss EAP 6, un utilisateur contenant une référence à un groupe inexistant retournait une erreur d'authentification lors de l'exécution de recherches principal à groupe dans LDAP pour charger des informations d'appartenance de groupe de l'utilisateur. L'authentification de l'utilisateur a été abandonnée.

Dans JBoss EAP 6.4, ce problème a été résolu en définissant l'attribut skip-missing-groups à « true » dans la configuration principal-to-group, ce qui permet d'ignorer les groupes manquants.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1105677

BZ#1073866 - Adding server-identity=ssl to SecurityRealm throws NPE in 6.3.0.DR2 (l'ajout de server-identity=ssl au SecurityRealm lance NPE dans 6.3.0.DR2)

Dans les versions précédentes de JBoss EAP 6, les mises à jour de runtime renvoyaient une exception NullPointerException à la liste de services ajoutés, donc le retrait de services, quand on en avait besoin, était très difficile.

Dans JBoss EAP 6.4, cette erreur a été corrigée et la liste des références de service est fournie pour les mises à jour de runtime.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1073866

BZ#1151434 - The outbound-connections element doesn't validate against XSD after removing connection (l'élément outbound-connexions ne valide pas XSD une fois qu'une connexion est supprimée)

En mode de gestion, quand une nouvelle connexion sortante LDAP est définie, une ressource sera instantiée qui contiendra les connexions ldap dépendantes.

Dans les versions précédentes de JBoss EAP 6, la ressource n'était pas supprimée après que la dernière connexion dépendante avait été supprimée.

Le comportement s'est produit parce que le marshaling XML a cru que les connexions sortantes ldap du modèle étaient définies et a donc écrit l'élément <outbound-connections> pour qu'il les contienne. Comme il n'y avait pas de connexions dans le modèle, cet élément est resté vide, qui n'est pas valide selon le schéma.

Remarque : l'analyseur est tolérant de ce fait et cela n'empêche pas le démarrage d'un autre serveur.

Dans cette version du produit, la ressource est supprimée dès que la dernière dépendance a été supprimée et l'analyseur voit maintenant qu'il n'y a aucune connexion sortante définie, donc un élément <outbound-connections> vide n'est plus écrit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1151434

BZ#908236 - Defining a secure socket for http management without a security realm results in a NullPointerException (définir un socket sécurisé pour la gestion http sans domaine de sécurité dans une NullPointerException)

Dans les versions précédentes de JBoss EAP 6, la validation de modèle n'a pas été mise en place pour veiller à ce que l'interface de gestion HTTP configurée pour activer SSL référençait également un domaine de sécurité pour obtenir son SSLContext.

Sans la validation, le SecurityRealm (domaine de sécurité) était nul, ce qui enclenchait une exception NullPointerException.

Dans cette version, les mises à jour d'horaire s'appliquent au modèle de gestion et des vérifications supplémentaires sont effectuées pour veiller à ce que le domaine de sécurité soit associé à l'interface de gestion HTTP, par SSL, soit activé.

Si un utilisateur tente de définir une interface de gestion HTTP par SSL mais pas de SecurityRealm, un message d'erreur sera reporté à la place de NullPointerException.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=908236

BZ#1129400 - Unable to create resource-adapter using HTTP management interface (impossible de créer un adaptateur de ressources utilisant l'interface de gestion HTTP)

Dans les versions précédentes de JBoss EAP, la logique de l'opération consistant à ajouter une ressource resource-adapter exige que l'adresse ciblée soit représentée comme liste l'éléments de DMR ModelType.PROPERTY.

Cela signifie que les clients de gestion basés-HTTP qui utilisent JSON ne peuvent pas créer d'opérations fiables en utilisant le format espéré (car représenter l'élément $PROPERTY dans la syntaxe JSON peut être problématic)

Dans cette version de JBoss EAP 6, le handler de l'opération add de l'adaptateur de ressources a été mis à jour pour utiliser le code d'analyse de l'adresse standard, plus tolérant des différences de mise en forme. En conséquence, les opérations qui ajoutent un adaptateur de ressources par l'interface HTTP et JSON, comme dans l'exemple ci-dessus, réussissent maintenant comme prévu.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1129400

BZ#1133961 - XML parsing mandating the 'force' attribute on username-to-dn even though it has a default value. (XML rendant obligatoire l'attribut 'force' sur username-to-dn même s'il possède une valeur par défaut.)

Dans JBoss EAP 6, quand un élément username-to-dn est défini pour une autorisation basée LDAP avec des domaines de sécurité, le schéma décrit un attribut optionel; force.

Dans les versions précédentes du produit, l'analyseur était conçu pour assumer que cet attribut était obligatoire.

Cela a entraîné que des configurations que l'on estimait comme étant valides d'être rejetées par l'analyseur quand l'attribut optionel était omis.

Dans cette version, l'analyseur a été mis à jour pour refléter le fait que l'attribut est optionel et les configurations qui omettent l'attribut force seront maintenant traitées correctement par l'analyseur.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1133961

BZ#1052821 - Unnecessary DNS lookup when accessing web console with https (recherche DNS inutile quand on accède à la console web par https)

Si un client se connecte au serveur et que la session SSL est initiée, il y a une tentative de résoudre le nom d'hôte de clients. Si le nom de client correspond à une adresse, il faut procéder à une recherche DNS pour découvrir le nom. Cela a un impact de performance sur chaque connexion de client distant pendant que la recherche DNS est effectuée. De plus, si le serveur DNS n'est pas disponible, cela peut occasionner un retard important.

Ce problème a été résolu dans la version de JBoss EAP 6.4. Une recherche DNS est maintenant éliminée du serveur quand un client tente de se connecter et d'établir une session SSL.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1052821

Transaction Manager

BZ#1162882 - JBTM-2188 - Some code that writes to the file store is missing PrivilidgedAction blocks (une partie du code qui écrit dans le file store ne possède pas de blocs PrivilidgedAction)

Dans les versions précédentes de JBoss EAP 6, quand le Security Manager était activé, alors le Narayana Transaction Manager ne pouvait ni lire, no écrire à partir des fichiers du object store géré par la classe FileSystemStore.

C'est parce que, lorsque le gestionnaire de sécurité est utilisé, il vérifie que le code possède les autorisations d'accès au système de fichier. Ce processus vérifie la chaîne d'appels de méthode entièrement, ce qui signifie qu'il existe une chance que certaines classes ne sont pas autorisées à accéder au système de fichiers.

La solution implémentée dans cette version est d'accéder au système de fichiers en tant qu'entité privilégiée (AccessController.doPrivileged()), ce qui réduit la pile de classes que le gestionnaire de sécurité accepte comme ayant un accès privilégié au système de fichiers.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1162882

BZ#1133346 - XA Recovery scans can stall JBoss startup (le scanning du recouvrement XA peut interrompre le démarrage de JBoss)

Dans JBoss EAP 6, un recouvrement de transaction débute en interrogeant les ressources sur leur avis à propos des branches de transactions incertaines, en utilisant les "RecoveryHelpers" fournis par d'autres systèmes. Quand un déploiement enregistre un de ces « helpers », un verrou se met en place. On obtient le même verrou quand on recouvre une ressource.

Si la ressource est lente à remplir une demande de recouvrement, alors le déploiement du sous-système (qui attend le verrou) sera retardé par là même.

Dans cette version, la contention du verrou est endommagée et les sous-systèmes sont déployés comme on s'y attend.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1133346

BZ#1113225 - CMR: TX log does not show participants after crash. (CMR : le journal TX n'affiche pas les participants suite à un crash)

Dans les versions précédentes de JBoss EAP 6, les outils de lecture des journaux de transaction n'exposaient pas les enregistrements CMR.

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

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1113225

BZ#1077156 - Not possible to start XTS transaction on IPv6 with server bound to ::1 (impossible de démarrer une transaction XTS sur IPv6 avec un serveur lié à ::1)

Dans un version précédente de JBoss EAP 6, il n'était pas possible de démarrer une transaction XST sur IPv6 avec un serveur lié à l'adresse ::1. C'est parce que cette partie de l'adresse doit être comprise entre crochets verticaux [::1].

Ce problème a été résolu en sectionnant l'URL en sections distinctes et en insérant des crochets verticaux selon les besoins avant qu'il soit passé au XTS core.

Notez que si vous utilisez le commutateur -b dans un commentaire d'interface CLI, n'insérez pas la portion d'adresse de l'URL dans des crochets verticaux car c'est contraire à la spécification et empêchera les services web de démarrer.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1077156

BZ#1032641 - IllegalStateException from periodic recovery when server is reloaded with XA datasource being defined (IllegalStateException en provenance du recouvrement périodique avec la source de données XA définie)

Dans les versions précédentes de JBoss EAP 6, l'exception IllegalStateException apparaissait parfois pendant les opérations de recouvrement de transactions.

Le système de recouvrement des transactions opère en interrogeant les ressources sur leur avis à propos des branches de transactions incertaines. Il utilise un "RecoveryHelper" que JCA enregistre pour le faire.

Lorsqu'une ressource est supprimée du système, le RecoveryHelper est désenregistré. Dans les versions précédentes du produit, il y avait une condition de concurrence critique dans le code qui faisait que si le retrait avait lieu lors d'un « scan de récupération », le « helper » (module d'assistance) n'était pas supprimé.

Cela implique que la récupération de transaction pouvait continuer d'utiliser des ressources, même si celles-ci avaient été supprimées du serveur (ce qui risquait de produire des exceptions IllegalStateExceptions).

Dans cette version, si le scanning de recouvrment actuel utilise la ressource, il devra attendre qu'il finisse avant de retirer le « helper » (assistant).

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1032641

BZ#1124861 - Issue with issue recovering AA with CMR, recovers OK but via orphan detection (problème de recouvrement d'AA avec CMR, recouvrement OK mais par détection d'enregistrements orphelins.

Dans les versions précédentes de JBoss EAP 6, si le serveur se plantait en cours de transaction XA, la ressource XA ne recouvrait pas imméditatement.

Le problème a été corrigé grâce à une mise à niveau de org.jboss.jbossts. Les transactions s'annulent et les journaux sont nettoyés comme il se doit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1124861

BZ#900289 - Domain management API does not expose JTS orphans from the transaction object store (l'API de gestion de domaine n'expose pas les enregistrements orphelins JTS de l'objet store de transactions)

Le sous-système de transactions contenu dans JBoss EAP 6 maintient un journal des transactions en attente. Ce journal est exposé à l'utilisateur de la console.

Dans certaines circonstances, une ressource comporte un journal d'une branche de transaction incertaine et pour laquelle il n'y a aucun journal de transaction de niveau supérieur correspondant (mais sur le disque, il y a un journal des participants). Ces journaux sont appelés « orphelins » et par défaut, ceux-ci n'étaient pas exposés dans les versions précédentes.

Ainsi, si le sous-système de transaction est configuré pour utiliser JTS, alors, ces enregistrements orphelins n'étaient pas automatiquement supprimés, ce qui entraînait une fuite de l'espace du stockage disponible

Dans cette version, l'utilisateur de la console peut remplacer la valeur par défaut en affectant la propriété de sous-système de transaction expose-all-logs à true. Ensuite, l'utilisateur de la console a la possibilité de supprimer manuellement ces fichiers journaux, empêchant ainsi la fuite.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=900289

JMX

BZ#1113242 - RemotingConnector & VersionedConectionFactory nécessitent une connexion configurable, des timeouts de connexion de version & un canal

Les versions précédentes de JBoss EAP 6 contenaient plusieurs timeouts de connexion JMX codées en dur. Dans cette version du produit, ces intervalles peuvent maintenant être configurés par une propriété système ou par des propriétés passées quand on crée la JMXConnectorFactory: JMXConnectorFactory.connect(serviceURL, environment);

L'ordre de priorité de ces paramètres de configuration est le suivant :

1. La valeur par défaut est de 30 secondes.
2. La propriété Env map remplace la valeur par défaut.
3. La propriété système remplace les valeurs passées dans l'env map.

Ordre de spécificité :

Propriétés de timeout spécifiques :

1. Timeout de canal : org.jboss.remoting-jmx.timeout.channel
2. Timeout de connexion : org.jboss.remoting-jmx.timeout.connection
3. Timeout de connexion de version : org.jboss.remoting-jmx.timeout.versioned.connection

Si la propriété org.jboss.remoting-jmx.timeout est définie et que la propriété spécifique ne l'est pas, la valeur standard sera utilisée à la place de la valeur par défaut.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1113242

BZ#1185118 - random NPE in RootResourceIterator (NPE aléatoire dans RootResourceIterator)

Dans les versions précédentes de JBoss EAP 6, la logique de façade qui expose les ressources de gestion en tant que Beans JMX créaient une lecture en double des ressources dépendantes inutile. Il était possible, pour cette deuxième lecture, de renvoyer une dépendance nulle si la ressource était dynamique et pouvait être supprimée à cause d'une action de « non-management » (comme par exemple, une ressource pour une file d'attente JMS temporaire ajoutée ou supprimée par une application).

De ce fait, l'appel de méthodes de serveur JMX, comme getMBeanCount() par des clients distants pouvait mener au hasard à des exceptions NullPointerExceptions de façon intermittente avec un message de journalisation ressemblant à ce qui suit :

[0m[33m18:38:11,612 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] (pool-2-thread-12) Unexpected internal error: java.lang.NullPointerException
				  at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:49)

Dans cette version du produit, la double lecture des ressources dépendantes a été supprimée, et la valeur de la lecture initiale (qui ne sera jamais "null") est utilisée. Cela garantit que l'exception NullPointerExceptions n'ait plus lieu.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1185118

Remoting

BZ#1126489 - Le marshalling échoue sur les objets qui ont besoin de permissions dans leur readObject

Quand le Java Security Manager est activé, l'exception java.security.AccessControlException était lancée quand un objet java.util.Calendar object était passé comme argument ou comme réponse à une méthode EJB, même avec une politique de sécurité de Java fournissant les permissions nécessaires. Ce problème a été réglé dans cette version. L'exception n'est plus lancée; le marshaling et l'appel EJB réussissent.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1126489

BZ#1161430 - JBoss Marshalling NullPointerException a lieu quand l'objet cloné a writeObject

L'exception JBoss Marshalling NullPointerException avait lieu quand un objet entrain d'être cloné avait un writeObject. Ce problème a été réglé dans cette version.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1161430

BZ#1153281 - Excessive logging when a JMS message is received (journalisation excessive suite à la réception d'un message)

L'événement de journalisation INFO apparaissait chaque fois qu'un message JMS était envoyé au serveur. Ce problème a été réglé dans cette version.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1153281

Console web

BZ#1107869 - Web Console errors out and ends the jbossas process completely (erreurs de console web qui terminent le processus jbossas complètement)

Quand JTS est activé dans la section « Transactions » de la console de gestion, il faut également définir l'attribut « Transactions » à la valeur « on » dans le sous-système JacORB.

Dans les versions précédentes de JBoss EAP 6, l'utilisateur n'était pas notifié de ces dépendances par la console de gestion.

Ce comportement a maintenant été corrigé dans cette version en ajoutant un contrôle de validation à la console.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1107869

BZ#1026823 - Provide a reliable way to clear "ROLE" headers set by "Run as" dialog (fournit une manière fiable de supprimer les en-têtes "ROLE" définis par le dialogue "Run as")

Dans les versions précédentes de JBoss EAP 6, on a signalé que lorsqu'un superutilisateur agissait pour le compte d'un autre utilisateur (par le lien Run As...), leurs rôles n'est pas redéfinis après que l'action ait eu lieu.

Ce problème a été résolu et les utilisateurs n'ont plus besoin de fermer la fenêtre du navigateur et d'accéder à nouveau la console web pour que les rôles soient définis à nouveau.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1026823

BZ#1017655 - Web services configuration validation errors (erreurs de validation de la configuration des services web)

Dans les versions précédentes de JBoss EAP 6, les valeurs non valides WSDL Host, WSDL Port et WSDL Secure Port sous Profils > Web > Services Web n'étaient pas rejetés par la console web.

Ce problème a été résolu dans cette version qui respecte les règles de validation du modèle de gestion. Les valeurs erronées ne sont dorénavant plus sauvegardées.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1017655

BZ#1029851 - management console - even after cancel the process to upload a deployment file, the content is added to data directory (console de gestion - même après l'annulation du processus de chargement d'un fichier de déploiement, le contenu est ajouté au répertoire de données)

Il y avait un problème dans des versions précédentes de JBoss EAP 6 qui provoquait le chargement de fichiers par l'écran Manage Deployment (gestion des déploiements), même si le chargement était annulé par l'utilisateur. Ce problème a été corrigé dans cette version.

Ce problème se posait parce que des versions précédentes du produit permettaient aux utilisateurs d'annuler une opération de chargement de fichier suite à une copie du fichier, mais avant que l'entrée de déploiement ait été ajoutée à domain.xml.

Dans cette version du produit, le flux de travail de la console a été modifié de façon à supprimer l'option « cancel » (annulation) pendant l'opération, empêchant ainsi les opérations incomplètes et les états non consistants entre les fichiers sauvegardés et les entrées de <deployment> dans domain.xml.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1029851

HornetQ

BZ#1165456 - HornetQ: Disallow SSLv3 [defense-in-depth]

Dans cette version de JBoss EAP 6, SSLv3 a été désactivé à cause de la vulnérabilité POODLE récemment découverte. Pour plus d'informations sur POODLE, consulter les sujets à propos de la sécurité dans Oracle : http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1165456

Serveur

BZ#1110635 - Deployment overlay feature does not work if a leading / is present on the overlay path (la fonction deployment-overlay n'opère pas si un / est présent au début du nom du chemin d'accés)

Dans les versions précédentes de JBoss EAP 6, l'ajout d'un préfixe « / » en début de deployment-overlay ne fonctionnait pas.

Dans JBoss EAP 6.4, ce problème a été résolu. Le deployment-overlay fonctionne avec ou sans « / » en début du nom du chemin d'accès)

deployment-overlay add --name=example-overlay --content=/lib/example.jar=eap6-overlay-example.jar --deployments=example.ear

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1110635

Services web

BZ#1157482 - EJB3 Web Service returns Invalid User on parallel invocations (le service web EJB3 retourne un nom d'utilisateur non valide pour les invocations parallèles)

Le service web EJB3 qui utilisait un token de nom d'utilisateur pour l'authentification échouait s'il était chargé avec des appels parallèles. Si le Service Web EJB3 utilisait le jeton de nom d'utilisateur pour l'authentification, il échouait sur les appels parallèles. Ce problème a été résolu dans cette version.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1157482

BZ#1115214 - CXF-5679, CXF-5724 - WS-S after upgrade fails with org.apache.ws.security.WSSecurityException: The signature or decryption was invalid (WS-S après que la mise à niveau ait échoué avec org.apache.ws.security.WSSecurityException: la signature ou le décriptage étaient non valides)

Les versions précédentes de JBoss EAP 6 comportaient une régression introduite dans Apache CXf 2.7.10 qui échouait avec l'erreur suivante :

org.apache.ws.security.WSSecurityException: la signature ou la décryption étaient non valides.

Ce problème a été résolu et la vérification de signature des messages WS-Security SOAP est effectuée corrrectement.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1115214

BZ#1121223 - Ensure EncryptedKey references BinarySecurityToken before it (veillez à ce qu'EncryptedKey référence BinarySecurityToken avant)

Dans les versions précédentes de JBoss EAP 6, CXF mettait le BinarySecurityToken référencé par l'élément EncryptedKey après l'élément EncryptedKey quand l'horodatage WSS n'était pas inclus dans le message SOAP.

Cela pouvait amener les récepteurs qui s'attendent à ce que le BinarySecurityToken référencé par EncryptedKey au-dessus de l'élément EncryptedKey à échouer car ils n'avaient pas traité le BinarySecurityToken quand ils avaient essayé de le trouver au cours du traitement de l'élément EncryptedKey.

Ce problème a été résolu en déplaçant BinarySecurityToken plus haut dans le message SOAP. Maintenant, les éléments EncryptedKey référencent toujours les BinarySecurityTokens ayant déjà été trouvés lors de l'analyse des messages SOAP.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1121223

BZ#1155490 - Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor (fuite de mémoire dans le HandlerChainSortInterceptor du client JBoss WS CXF)

Si le client JAX-WS était implémenté par un gestionnaire JAX-WS, invoquer la méthode de port de service indéfiniement résultait en fuite de mémoire. Ce problème a été résolu dans cette version.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1155490

EE

BZ#1029260 - Cannot use a ear-subdeployments-isolated attribute setting with a jboss-deployment-structure.xml (impossible d'utiliser une configuration d'attribut ear-subdeployments-isolated dans une jboss-deployment-structure.xml)

Si vous configuriez un attribut ear-subdeployments-isolated avec jboss-deployment-structure.xml et que vous mettiez un répertoire <EAR>/META-INF en dessous, l'indicateur d'isolation était remplacé par la configuration du sous-système.

Dans JBoss EAP 6.4, ce problème a été réglé. L'ordre de traitement a été mis à jour.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1029260

JPA

BZ#1131711 - HttpManagementService-threads consumes high cpu on org.jboss.as.jpa.hibernate4.management.QueryName.displayable()

Dans la version précédente de JBoss EAP 6, HttpManagementService-threads sur org.jboss.as.jpa.hibernate4.management.QueryName.displayable() ralentissait la performance à cause de l'utilisation intensive de la mémoire. Cela était dû aux nombre élevé d'appels à String.replace(). Ce problème a été réglé dans la derniére version de JBoss EAP 6.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1131711

BZ#1114726 - JPA entity class enhancement may not work for sub-deployments when other sub-deployments reference the entity classes (l'amélioration de la classe d'entité JPA ne fonctionne sans doute pas pour les sous-déploiements quand d'autres sous-déploiements référencent les classes d'entité)

Dans les versions précédentes de JBoss EAP 6, des classes d'entité des applications de l'utilisateur qui sont censées être réécrites par le fournisseur de persistance pendant le déploiement de l'application ne peuvent pas être réécrites. Pour cette raison, quand les sous-déploiements sont déployés en parallèle, et qu'il existe des références à des classes d'entité dans les déploiements secondaires au-delà du déploiement qui contient l'unité de persistance, la définition de classe d'entité est chargée avant d'être réécrite par le fournisseur de persistance, ce qui affecte la performance. Ce problème a été résolu dans la dernière version de JBoss EAP 6.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1114726

JMS

BZ#1070106 - Generic JMS adapter does not deploy correctly in domain mode. (l'adaptateur JMS standard ne se déploie pas correctement en mode de domaine)

Dans la versions précédente de JBoss EAP, les informations contextuelles n'étaient pas correctement vérifiées lors des opérations d'ajout. De ce fait, l'adaptateur JMS était déployé correctement en mode de domaine. Ce problème a maintenant été résolu dans la dernière version de JBoss EAP 6. L'adaptateur JMS standard peut maintenant être déployé en mode de domaine.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1070106

JCA, JMX

BZ#1150821 - JMX Datasource pool & jdbc statistics disappear if you enable validation (les statistiques de jdbc et de pool de source de données JMX disparaissent si on active la validation)

Dans la version précédente de JBoss EAP 6, les statistiques de jdbc et de pool de source de données JMX pouvaient disparaître si la validation avait été activée. Cela était dû à une référence à une partie du modèle de ressource, rendue invalide si le modèle était modifié. Ce problème est résolu dans la version actuelle de JBoss EAP 6. La référence à une partie du modèle de ressources ne tient plus dans l'ensemble des opérations.

Résultat : les statistiques de source de données ne disparaissemt pas.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1150821

Logging

BZ#1096053 - SyslogHandler doesn't handle multi-byte characters correctly (SyslogHandler ne traite pas les caractères multi-octets correctement)

Dans les versions précédentes de JBoss EAP, utiliser org.jboss.logmanager.handlers.SyslogHandler pour vous connecter à des caractères multi-octets risque de résulter en sorties corrompues enregistrées. Par exemple :

Mar 8 17:29:09 UNKNOWN_HOSTNAME java[9896]: SyslogHandler: ????????????

Ce problème a été résolu dans cette version et maintenant, les caractères apparaissent dans le journal comme on s'y attend.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1096053

BZ#1031448 - logging-profile works for a servlet, but doesn't for a JSP (logging-profile fonctionne dans le servlet mais pas pour JSP)

Dans une version précédente de JBoss EAP 6, les profils de journalisation fonctionnaient comme prévu avec un servlet, mais ne fonctionnaient pas avec JSP; tous les messages de journaux provenant de JSP allaient au contexte de journal du système.

Ce problème se présentait parce que le chargeur de classes sélectionné était un org.apache.jasper.servlet.JasperLoader avec un chargeur de classes parent du chargeur de classes qui était enregistré pour le contexte de journalisation.

Ce problème a été résolu en ajoutant une option au gestionnaire du journal pour qu'il puisse régulièrement chercher la présence d'un LogContext dans un parent du chargeur de classes.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1031448

BZ#1071695 - Infinite recursion when exception stack frame class lookup fails (récursivité à l'infini quand la recherche d'« exception stack frame class » échoue)

Lorsqu'il est configuré avec le formateur %E, le JBoss LogManager imprime d'où viennent les classes jar. S'il y a un problème de chargement de la classe, JBoss Modules affiche un avertissement. Dans certaines circonstances, le formateur d'exception déclenchera une récursivité à l'infinie entre le gestionnaire de journal en train de charger une classe et les modules qui impriment un avertissement.

Ce problème a été réglé dans JBoss EAP 6.4. La situation ne déclenche plus de récursion ou de logging à l'infini.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1071695

Chargement des classes

BZ#1155823 - Package certificate SecurityErrors triggered by MODULES-192 (certificat de package SecurityErrors déclenché par MODULES-192)

Dans les versions précédentes de JBoss EAP 6, le JarFileResourceLoader tentait de récupérer les certificats avant plutôt qu'après la lecture du flux de classe, ce qui faisait que les certificats n'étaient pas chargés.

Cela entraînait une SecurityError quand les classes signées étaient chargées simultanément par des threads multiples.

Dans cette version, le JarFileResourceLoader retire les certificats après avoir lu le flux de classes et les SecurityError n'ont plus lieu.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1155823

BZ#1172577 - Include additional sun.jdk dependencies (inclut des dépendances sun.jdk supplémentaires)

Dans les versions précédentes de JBoss EAP 6, certaines classes de JKD n'étaient pas exposées à l'application via le sun.jdk alors qu'elles auraient dû l'être quand on utilisait javax.sql.rowset.RowSetProvider JDK et java.lang.invoke.MethodHandleProxies dépendant du module sun.jdk.

Dans cette version, les applications pourront apercevoir ces packages lorsqu'ils dépendent du module sun.jdk  :

• com.sun.rowset
• com.sun.rowset.providers
• sun.invoke

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1172577

Gestion de domaine, Sécurité

BZ#1150024 - HeaderParser fails to handle delimiters in DigestAuthenticator (HeaderParser ne parvient pas à gérer les délimiteurs dans DigestAuthenticator)

Les versions précédentes de JBoss EAP 6 comportaient un bogue dans l'authentificateur Digest qui l'empêchait de gérer les délimiteurs placés dans une séquence d'échappement correctement dans la limite des valeurs contenues dans l'en-tête d'authentification.

De plus, l'utilitaire add-user n'échappait pas les noms d'utilisateur qui contenaient le caractère d'échappement (\) correctement.

De ce fait, les requêtes d'authentification valides étaient rejetées de façon erronnée.

Dans cette version, l'analyse des en-têtes a été re-travaillé dans le mécanisme d'authentification de Digest et l'utilitaire add-user utilisateur échappe maintenant correctement la barre d'échappement dans les noms d'utilisateur, ce qui permet à l'authentification de se produire comme prévu.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1150024

BZ#1153854 - Management Interface: SSL configuration does not allow disabling protocols (interface de gestion : la configuration SSL ne permet pas de désactiver les protocoles)

Dans les versions précédentes de JBoss EAP 6, il a été constaté qu'alors qu'il était possible de spécifier le protocole de requête pendant la création du SSLContext lors de la configuration des domaines de sécurité, pour fournir un SSLContext, il n'était pas possible de spécifier les protocoles ou les suites cipher à prendre en charge sur le SSLEngine sous-jacent.

Cela signifie qu'il n'était pas possible de sélectionner un groupe de protocoles et de suites cipher sufisamment puissant pour les connexions SSL.

Dans cette version, les utilisateurs sont maintenant en mesure de spécifier un ensemble de protocoles et de suites cipher activés dans la définition du domaine de sécurité. Ils seront mis en correspondance avec les protocoles pris en charge et les suites cypher pour configurer le SSLEngine sous-jacent.

Aussi, les protocoles activés seront TLSv1, TLSv1.1 et TLSv1.2 par défaut si aucune configuration n'est spécifiée. SSLv3 (ou antérieur) n'est plus activé par défaut et il est possible que les protocoles et les suites cipher soient davantage configurés.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1153854

Clustering

BZ#993041 - RuntimeException in org.jboss.as.web.session.ClusteredSession.access

Dans les versions antérieures de JBoss EAP 6, quand on accédait à une session web distribuée alors qu'un autre nœud quittait brusquement le cluster, une acquisition de verrou pouvait échouer. Lorsque cela se produisait, cela se traduisait par le message d'exception :

RuntimeException: JBAS018060: Exception acquiring ownership of <session-id>

La cause principale de ce problème est que l'acquisition de verrou ne tient pas compte du fait qu'un nœud de cluster puisse quitter le cluster exactement au même monent, ce qui entraîne l'échec d'acquisition du verrou.

Cette question a été résolue et l'exception ne se présente plus.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=993041

Sécurité

BZ#1150020 - add-user utility doesn't escape names correctly (l'utilitaire add-user n'échappe plus les noms correctement)

L'utilitaire « add-user » de JBoss EAP 6 effectue une itération de la valeur utilisée comme clé dans un fichier de propriétés et échappe toutes les occurrences des caractères spéciaux.

Dans les versions précédentes du produit, une erreur dans la façon dont les caractères ont été vérifiés aboutissait à ce que seule la première instance du caractère « égal » (=) était échappée. Si un nom d'utilisateur contenait un caractère « égale » ultérieur, il n'était pas correctement échappé, rendant ainsi le fichier de propriétés généré inutilisable.

Dans cette version, la manipulation d'un caractère spécial est maintenant corrigée pour gérer toutes les occurrences du caractère « égal » et tous les noms d'utilisateur contenant plusieurs caractères et ils sont correctement écrits dans le fichier de propriétés

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1150020

BZ#979369 - Different behaviors of HttpSession creation with programmatic login() (différents comportements de création HttpSession avec login() programmatique)

Dans les versions précédentes de JBoss EAP 6, le comportement de création HttpSession est différent si utilisé avec le login programmatique suivant :

• Sans SSO : la session n'est pas créée quand on appelle la méthode login(). Ainsi, les requêtes suivantes sont authentifiées
• Avec SSO non-clusterisé : la session est créée lors de l'appel de la méthode login(), mais le premier appel ne définit pas le statut d'authentification. Les requêtes suivantes sont désauthentifiées; l'utilisateur est authentifié après le deuxième appel de méthode login() parce que la session est déjà présente.
• Avec SSO clusterisé : la session est créée quand on appelle la méthode login() et que les requêtes suivantes sont authentifiées

Ce problème a été réglé dans la version actuelle de JBoss EAP 6. La classe org.apache.catalina.authenticator.AuthenticatorBase.ALWAYS_USE_SESSION possède une nouvelle option pour toujours pouvoir créer une option.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=979369

BZ#949737 - Session replication broken by NegotiationAuthenticator valve (réplique de session endommagée par la valve NegotiationAuthenticator)

Les versions précédentes de JBoss EAP 6 n'incluent pas une option pour définir les mécanismes d'authentification globale comme dans JBoss EAP 5. Pour contourner cette limitation, les conseils pour activer l'authentification SPNEGO était d'ajouter manuellement la valve au jboss-web.xml du déploiement touché.

La conséquence est que la valve était appelée plus tôt dans l'appel, et précédait la valve responsable de la mise en cluster. Cela signifiait que la valve de Négociation de JBoss créait une nouvelle session HTTP et la valve de Clustering ne recevait pas les notifications concernant la durée des sessions. Comme la valve de clustering ne recevait pas la notification qu'il fallait, la session n'était pas clusterisée et la réplication était affectée.

Cette version de JBoss EAP 6 prend désormais en charge la définition des mécanismes d'authentification globaux. Cette approche déconseille l'ajout manuel de la valve au jboss-Web.xml de l'application web

La valve d'authentification SPNEGO sera maintenant appelée après la valve de clustering afin que la valve de clustering reçoive les notifications requises relatives au cycle de vie de la session et qu'elle réplique la session correctement.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=949737

Gestion de domaine, Support IPv6

BZ#1149612 - User is able to use any-ipv6-address interface on IPv4 environment (l'utilisateur peut utiliser l'interface any-ipv6-address dans un environnement IPv4)

Dans la précédente version de JBoss EAP 6, la logique pour vérifier et rejeter la combinaison d'une configuration any-ipv6-address pour une interface et une propriété système java.net.preferIPv4Stack=true avait lieu lors de l'installation du service d'interface réseau, au lieu d'attendre que le service démarre.

De ce fait, la vérification pouvait avoir lieu sur des processus de contrôleur hôte qui n'avaient pas besoin du service de l'interface, entraînant de fausses défaillances si le processus de serveur qui utiliserait la configuration de l'interface n'avait pas la valeur java.net.preferIPv4Stack=true définie.

Dans cette version, le contrôle de consistency a été différé jusqu'à ce que le service de l'interface démarre, assurant ainsi que le service soit bien utilisé sur ce processus.

Maintenant, un serveur qui ne possède pas de java.net.preferIPv4Stack=true défini peut utiliser any-ipv6-address dans la configuration de l'une de ses interfaces même si le contrôleur de domaine or son propre contrôleur d'hôte n'a pas java.net.preferIPv4Stack=true défini.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1149612

mod_cluster

BZ#1083563 - Mod_cluster draining pending requests coud fail since deployments are missing dependency on mod_cluster service (seen on JDK8) (les requêtes de drainage en attente de Mod_cluster pouvaient échouer car des déploiements n'avaient pas de dépendance dans le service mod_cluster) (a été vu dans JDK8)

Le sous-système de mod_cluster se drainait et cela faisait échouer les requêtes en attente. Ce problème a été résolu dans cette version.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1083563

BZ#1044879 - If "Balancer name includes" uppercase letter in name then mod_cluster will not maintain sticky sessions (si le nom de l'équilibreur inclut des lettres majuscules dans le nom, alors mod_cluster ne maintiendra pas les sessions sticky)

Dans la version précédente de JBoss EAP 6, le module modcluster ne maintenait pas de session sticky si un nom d'équilibrage des charges comprenanit des lettres majuscules.

Ce problème a été corrigé dans cette version en rendant la validation des nom d'équilibreurs de charge sensibles à la casse.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1044879

RESTEasy

BZ#1090487 - Resteasy secure processing to be turn on by default to apply entity expansion limit (le traitement sécurisé resteasy doit être activé par défaut pour pouvoir appliquer la limite d'expansion de l'entité)

Deux nouveaux paramètres RESTEasy ont été créés pour améliorer la sécurité de traitement des documents org.w3c.dom.Document. Ce sont tous les deux des paramètres de contexte context-param et ils sont configurés dans le fichier web.xml de l'application.

Nom : resteasy.document.secure.processing.feature Valeur par défaut : true Description : Impose des contraintes de sécurité pour traiter les documents org.w3c.dom.Document et les représentations d'objet JAXB.

Nom : resteasy.document.secure.disableDTDs Valeur par défaut : true Description : Empêche les DTD dans les documents org.w3c.dom.Document et les représentations d'objets JAXB

Notez que Xerces 2.9.1.redhat-6 inclus dans EAP 6.4.0 ne supporte pas la limite max d'attributs

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1090487

BZ#1088956 - MalformedByteSequenceException in Namespace test on Windows

Dans une version précédente de JBoss EAP 6, quand l'encodage n'était pas spécifié dans le corrps de contenu d'une requête de client, RESTeasy retournait une réponse dans l'encodage du serveur, et non pas dans l'encodage de la requête d'origine.

Ce problème a été résolu dans cette servions en définissant UTF-8 comme encodage par défaut si aucun encodage n'est requis par le client.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1088956

BZ#899666 - RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception (RESTEasy: paramètre cfg. vide javax.ws.rs.Application produit une exception)

Le composant RESTEasy fourni dans les versions précédentes de JBoss EAP 6 envoyait une erreur java.lang.StringIndexOutOfBoundsException: String index out of range: 0 quand l'option de configuration javax.ws.rs.Application du fichier WEB-INF/web.xml restait vide.

Le problème a été corrigé dans cette version par une mise à niveau du composant RESTeasy.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=899666

Installateur

BZ#977805 - Starting JBoss Administration Console from start menu is not working on Solaris (Démarrer la console d'administration de JBoss à partir du menu de démarrage ne fonctionne pas dans Solaris)

À cause du problème gvfs-open de Solaris, les raccourcis de menu de démarrage de la console d'administration de Solaris ne fonctionnent pas pour une instance JBoss EAP 6 qui a été installée par un installateur.

À partir de JBoss EAP 6.4, les raccourcis de menu de la console d'administration ne seront plus créés pour les instances JBoss EAP 6 qui ont été installées à l'aide de l'installateur sur Solaris.

La console d'administration est accessible directement dans un navigateur web. Si configurée avec les ports par défaut, les URL de la console d'administration sont les suivants : En mode autonome : http://localhost:8080/console En mode de domaine : http://localhost:9990/console

Voir http://bugzilla.redhat.com/show_bug.cgi?id=977805

BZ#1032892 - Unable to use tab filling for path starting with a drive letter on windows. (impossible d'utiliser l'onglet de saisie semi-automatique pour un chemin d'accès commençant par une lettre de lecteur dans WIndows)

Dans les versions précédentes de JBoss EAP 6, l'onglet de saisie semi-automatique pour les chemins de répertoire qui commencent par une lettre de lecteur ne fonctionnait pas dans l'installateur de la console de JBoss EAP 6 sur le serveur Microsoft Windows.

Lorsque vous entriez un chemin d'accès qui commençait par une lettre de lecteur, par exemple C:\ et que vous appuyiez sur la touche +Tab+, rien ne s'affichait. Normalement, on s'attend à ce que le contenu de ce répertoire s'affiche.

Le problème a été corrigé dans cette version et l'onglet de saisie semi-automatique fonctionne maintenant correctement.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1032892

CDI/Weld, Gestionnaire de transactions

BZ#1098127 - "Failure while notifying an observer of event" in CDI transactional observer methods with remote EJB call using JTS ("Échec quand on notifie un observateur d'événement" dans les méthodes d'observateur transactionnel CDI avec un appel EJB distant utilisant JTS)

Dans les versions précédentes de JBoss EAP 6, lancer un événement CDI à partir d'un client EJB distant par l'intermédiaire de transactions JTS résultait en échec d'invocation des observateurs transactionnels sur le serveur.

Cela a été réglé en corrigeant la sélection d'espace-noms JNDI pour les rappels de synchronisaton de transaction dans le code d'intégration Weld.

Les observateurs transactionnels sont maintenant invoqués dans des scénarios de transactions distribuées.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1098127

Nommage

BZ#1131626 - ERROR: remote lookup Channel end notification received, closing channel Channel ID is seen when looking up a remote queue (ERREUR : la recherche distante de notification de fin de canal est reçue; la fermeture de l'ID de canal apparaît quand on cherche une file d'attente distante)

Dans les versions précédentes de JBoss EAP 6, on pouvait rencontrer une erreur quand on effectuait une recherche sur une file d'attente distante dans un EJB, même si l'opération réussissait.

Une mise à niveau de jboss-remote-naming a résolu ce problème.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1131626

Gestion de domaine, Testsuite

BZ#1078062 - ManagementClientContentTestCase is sometimes fails (different JDK dor master and slave)

Dans une version précédente de JBoss EAp 6, le mappage utilisé dans le mécanisme de stockage du management-client-content retournait des valeurs d'attribut 'hash' différentes pour la ressource management-client-content=rollout-plans sur différents processus d'un domaine.

Dans JBoss EAP 6.4, cette erreur a été résolue en mettant à jour le mappage grâce à un ordonnancement consistant pour stocker le management-client-content. L'attribut 'hash' de la ressource management-client-content=rollout-plans renvoie la même valeur sur tous les processus d'une domaine.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1078062

JCA

BZ#1107120 - Failures when deploying MySQL JDBC driver to EAP 6.x (échecs quand on déploie un pilote MySQL JDBC dans EAP 6.x)

Dans une version précédente de JBoss EAP 6, un bogue empêchait le pilote MySQL JDBC de se déployer dans certaines circonstances.

Le déploiement échouait en informant l'utilisateur que le déploiement existait déjà. Toute tentative de supprimer le déploiement existant échouait également.

Ce problème a été résolu et le pilote se déploie maintenant comme on s'y attend.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1107120

Console web - UX

BZ#1016546 - RBAC: Unclear error message when trying to configure Auditor role as Administrator (RBAC : message d'erreur non clair quand on essaie de configurer un rôle d'auditeur en tant qu'administrateur)

Dans les versions précédentes de JBoss EAP 6, si un utilisateur tentait d'exécuter une opération qu'il n'a pas l'autorisation d'exécuter, il recevait le message d'erreur suivant :

You don't have the permissions to access this resource! (Vous n'avez pas la permission d'accéder à cette ressource)

Cela peut être source de confusion pour les utilisateurs car ils tentent d'effectuer une opération sans tenter d'accéder à une ressource. Ce texte d'erreur est clarifié dans une version ultérieure du produit :

You don't have the permissions to perform this operation! (Vous n'avez pas les permissions d'effectuer cette opération)

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1016546

Sécurité, Web

BZ#952518 - run-as does not work for Servlet init() and destroy() methods (run-as ne fonctionne pas pour les méthodes de servlets init() et destroy()

Dans les versions précédentes de JBoss EAP 6, il y avait un problème avec l'identité run-as qui n'était pas utilisée pour Servlet.init(), ce qui allait à l'encontre de la spécification Java Servlet 2.4.

C'est parce que le RunAsListener n'existait pas dans JBoss EAP 6 alors qu'il existait dans JBoss EAP 5.

Ce problème a été résolu dans cette version et le produit adhère maintenant à la spécification à ce sujet.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=952518

Scripts et Commandes, Sécurité

BZ#901193 - add-user check is not i18n, while prompt is (la commande add-user n'est pas internationalisée, mais l'invite l'est)

L'utilitaire add-user de JBoss EAP 6 invite les utilisateurs à confirmer l'action qu'ils sont sur le point de prendre sur la locale en cours. Quand une entrée utilisateur est comparée à d'autres traductions, le texte de l'entrée utilisateur est convertie en minuscules mais la valeur de la traduction ne l'est pas.

Cela signifie que l'utilitaire add-user n'était pas en mesure d'identifier quelle option l'utilisateur avait sélectionnée à cause de la différence en terme de comparaison et reportait une erreur aux utilisateurs pour leur dire qu'ils n'avaient pas sélectionné une valeur valide.

Dans cette version, les entrées utilisateur et les valeurs traduites à la fois sont comparées et converties en minuscules avant toute comparaison. Les réponses internationalisées sont maintenant acceptées correctement avec l'utilitaire add-user pour les dialogues de confirmation.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=901193

Support IPv6

BZ#900564 - Wrong format of IPv6 addresses in log entries (format des adresses IPv6 erroné dans les entrées de journalisation)

Les adresses IPv6 journalisées dans les versions précédentes de JBoss EAP 6 n'étaient pas encadrées entre des crochets verticaux comme demandé. Dans cette version, la manipulation des adresses IPv6 a été adressée, et ils figurent entre crochets dans les journaux, comme prévu.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=900564

Serveur web Apache (httpd) et Connecteurs

BZ#1188769 - snmpd.conf isn't loaded on Windows except it is in conf (snmpd.conf n'est pas chargé dans Windows mais il l'est dans conf)

On a remarqué que les paramètres de configuration SNMPConf étaient ignorés dans les versions précédentes de JBoss EAP 6 installées sur les systèmes Windows, ce qui amenait l'agent à démarrer sur le port 161.

Dans cette version, la configuration snmpd.conf.sample a été ajoutée à etc/httpd/conf et est honnorée comme il se doit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1188769

PicketLink

BZ#1170792 - SAML11TokenProvider and SAML20TokenProvider do not take CLOCK_SKEW into account (SAML11TokenProvider et SAML20TokenProvider ne prennent pas CLOCK_SKEW en compte)

Dans les versions précédentes de JBoss EAP 6, `SAML11TokenProvider` et `SAML20TokenProvider` ne prennaient pas l'attribut `CLOCK_SKEW` en compte lors de la validation des tokens.

De ce fait, si l'horloge qui se trouve sur l'hôte de validation et celle qui se trouve sur le STS ne sont pas synchronisées, l'authentification peut échouer.

Dans cette version, `SAML11TokenProvider` et `SAML20TokenProvider` ont été modifiés pour honnorer `CLOCK_SKEW` pendant la validation du token. Les horloges qui se trouvent sur l'hote de validation et STS peuvent être mal alignées dans la limite `CLOCK_SKEW`, dans lequel cas, l'authentification peut réussir.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1170792

CLI

BZ#1139515 - cli deploy command with unpaired quotation mark causes StringIndexOutOfBoundsException (la commande de déploiement cli associée à des guillemets non appariés cause l'exception StringIndexOutOfBoundsException)

Dans les versions précédentes de JBoss EAP 6 sur Windows, l'outil jboss-cli.bat de déploiement d'application envoyait une exception quand l'utilisateur tentait d'utiliser la fonctionnalité de saisie semi-automatique via la touche TAB pour compléter une expression entre guillemets anglais (").

Tenter cette action avait le résultat suivant :

java.lang.StringIndexOutOfBoundsException: String index out of range: -1

Dans cette version, l'exception n'aura pas lieu.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1139515

Hibernate

BZ#1132207 - HHH-9389 Foreign key column name for table mapping @ElementCollection uses entity class name instead of specified entity name (Le nom de colonne de la clé étrangère HHH-9389 du tableau mappant @ElementCollection utilise le nom de la classe d'entité au lieu du nom d'entité spécifié)

Dans les versions précédentes de JBoss EAP 6, le nom d'attribut de @Entity(name="...") n'est pas pris en considération lors du traitement informatique du préfixe des colonnes de clés étrangères utilisées pour faire correspondre le tableau d'entités aux tableaux de propriétés @ElementCollection.

De ce fait, le préfixe de clé étrangère calculé est un nom de classe d'entité au lieu du nom fourni par l'annotation @Entity.

Dans cette version, le nom de l'annotation @Entity est utilisé pour calculer le préfixe du nom de la clé étrangère. Par exemple, la classe publique ``@Entity(name="prod")` résultera en clé étrangère (pour le tableau @ElementCollection) avec le préfixe 'prod' au lieu de 'Product'.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1132207

RPM

BZ#1124516 - File snmpd.conf.sample is missing in rpm (le fichier snmpd.conf.sample est manquant dans le rpm)

Le fichier 'httpd/conf.d/snmpd/snmpd.conf.sample' était manquant des versions suivantes des RPM 'mod_snmp' :

• mod_snmp-2.4.1-7.GA.ep6.el5.i386.rpm

• mod_snmp-2.4.1-7.GA.ep6.el5.x86_64.rpm

• mod_snmp-2.4.1-8.GA.ep6.el6.i386.rpm

• mod_snmp-2.4.1-8.GA.ep6.el6.x86_64.rpm

• mod_snmp-2.4.1-9.GA.ep6.el7.x86_64.rpm

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

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1124516

JSF

BZ#1096905 - InstantiationException on WeldApplicationFactory when switching to JSF 1.2 in EAP 6.2 (InstantiationException dans WeldApplicationFactory quand on passe à JSF 1.2 dans EAP 6.2)

JBoss EAP 6 permet aux utilisateurs de choisir une version JSF de déploiement en utilisant les descripteurs liés au déploiement.

Ceci, cependant, ne fonctionne pas correctement lorsque le déploiement utilise également CDI. Il n'est actuellement pas possible d'avoir deux déploiements différents utilisant différentes versions de JSF, si les deux déploiements utilisent également CDI.

Une exception est alors levée et le déploiement échoue avec l'erreur suivante :

java.lang.InstantiationException: org.jboss.as.weld.webtier.jsf.WeldApplicationFactory

Bien que l'utilisation de JSF 1.2 avec CDI n'est pas officiellement supportée, puisque JSF 1.2 est une technologie EE5 et que CDI est une technologie EE6, il est toujours possible de faire fonctionner JSF 1.2 avec CDI pour tous les déploiements à l'aide de la solution de contournement suivante :

1. Définir la version JSF par défaut à 1.2 dans EAP en exécutant la commande suivante dans jboss-cli : /subsystem=jsf/:write-attribute(name=default-jsf-impl-slot,value=1.2)

2. Configurer la dépendnace JSF 1.2 du module Weld à la fois dans /modules/system/layers/base/org/jboss/weld/core/main/module.xml et`/modules/system/layers/base/org/jboss/as/weld/main/module.xml en changeant la ligne <module name="javax.faces.api"/> en <module name="javax.faces.api" slot="1.2" />

3. Redémarrez le serveur.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1096905

EJB

BZ#1188420 - EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations (EJB Asynchrone passe POJO par référence menant à des erreurs de ClassCastException dans les invocations distantes)

Dans cette version de JBoss EAP 6, un appel asynchrone EJB via l'interface distante de l'EJB, d'un client à un EJB en cours d'exécution dans la même JVM, échoue avec une ClassCastException.

C'est parce que les requête/réponse ne sont pas marshalées comme il se doit et que le client et l'EJB n'utilisent pas le même chargeur de classe.

Cela devrait être résolu dans une version ultérieure et que la requête/réponse seront marshalées comme il se doit car il s'agit un appel de l'interface distante, ce qui permet au client et à l'EJB d'utiliser des chargeurs de classes différentes et à ne pas échouer avec une ClassCastException.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1188420

BZ#1020074 - EJB clients do not attempt to reconnect to any receivers until all receivers have failed (les clients EJB ne tentent pas de se reconnecter à un destinataire tant que tous les récepteurs n'ont pas échoué)

Cette version de JBoss EAP 6 comporte un problème avec le composant EJB.

Les clients EJB doivent normalement tenter de se reconnecter aux récepteurs lorsqu'ils détectent une connexion ayant échoué. Au lieu de cela, la tentative de connexion n'a pas lieu tant qu'il n'y a aucun récepteur disponible.

En conséquence, cette méthode n'est pas efficace dans une configuration d'équilibrage de charge. La cause de ce problème est toujours sous investigation.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1020074

BZ#952746 - Fix transaction recovery failures involving remote EJB resource (corriger les échecs de recouvrement de transactions comprenant une ressource EJB distante)

Dans cette version de JBoss EAP 6, les opérations de recouvrement de transactions peuvent échouer si elles impliquent des ressources EJB qui se sont plantées.

Le problème se présente parce que quand une connexion se rompt entre le serveur et le client (plus précisément lorsque le client se plante et est redémarré) ; le serveur et le client ne communiquent pas entre eux automatiquement.

Dans ces scénarios, le serveur ne pourra pas savoir que le client a démarré à nouveau, ce qui signifie que le processus de recouvrement EJB tx ne saura pas avec quels nœuds EJB communiquer.

Ce problème est sous investigation et une solution est en cours.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=952746

BZ#1036040 - Calling EJB with "REQUIRES_NEW" transaction attribute creates two transactions (appeler un EJB avec un attribut de transaction "REQUIRES_NEW" crée deux transactions)

Dans cette version de JBoss EAP 6, un problème dans le composant EJB entraîne la transaction à indiquer un nombre incorrect de transactions traitées.

C'est parce que les intercepteurs de CMTTxInterceptor et de LifecycleCMTTxInterceptor créent deux transactions lors de la gestion des demandes de l'EJB. L'une est une opération factice et l'autre est utilisée pour la gestion des ressources. De ce fait, la demande d'EJB est comptée deux fois dans les statistiques.

Il n'y a pas de solution de contournement possible pour l'instant.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1036040

BZ#990102 - Concurrent access timeout -- could not obtain lock within 5000 MILLISECONDS (timeout d'accès simultané -- n'a pas pu obtenir de verrou dans la limite de 5000 millisecondes)

Cette version de JBoss EAP 6 comporte un bogue pouvant produire un timeout d'accès simultané lorsqu'un client EJB, invoquant une méthode sur un bean stateful dans un cluster de "transfert" transfère l'appel aux beans stateful dans un cluster « cible », et recommence. Les invocations sont en série ; le client n'appellera pas une méthode sur un bean tant qu'il n'aura pas obtenu de réponse de l'appel précédent. Quand un des serveurs du cluster est arrêté, l'erreur se produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=990102

Web

BZ#1076439 - NIO2 Connector is not properly reloaded during reload operation on IBM JDK (le connecteur NIO2 ne se recharge pas correctement lors de l'opération de rechargement dans JDK d'IBM (IBM JDK 1.7 et 1.8)

Si cette version de JBoss EAP 6 commence par IBM JDK 1.7 ou IBM JDK 1.8 et qu'on fait une tentative de rechargement du serveur, le message erreur suivant apparaîtra dans la journalisation.

ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-6) JBWEB003043: Error initializing endpoint: java.net.BindException: Address already in use

Cette erreur est provoquée par un problème avec le JDK IBM qui fait que le connecteur NIO2 ne recharge pas correctement et la charge originale est toujours en cours d'exécution. Pour contourner ce problème, utilisez un connecteur différent (à noter que chaque connecteur possède ses propres caractéristiques) ou utiliser un JDK différent.

Ce problème devra être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1076439

BZ#918130 - JBossWeb connectors start before application deployments are completed in EAP 6 (les connecteurs JBossWeb démarrent avant que les déploiements d'applications soient complétés dans EAP 6)

Un problème de synchronisation avec les connecteurs JBossWeb au démarrage a été découvert. Les connecteurs démarrent et acceptent des demandes avant que les applications soient tout à fait déployées.

Dans ce cas, les connexions clientes reçoivent un message 404 via un équilibreur de charge ou directement à JBoss EAP. Ce problème concerne les versions JBoss EAP 6.0.1 ou supérieures.

Aucune solution de contournement est actuellement disponible et le problème est sous investigation.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=918130

BZ-1086399 - WebSockets should support CDI as per JSR-356 (les websockets doivent supporter CDI selon JSR-356)

L'application JBoss EAP 6.4 WebSocket fournit un support complet d'injection de dépendance des points de terminaison de serveur; cependant, elle ne fournit pas de services CDI pour les clients de points de terminaison.

Le support CDI est limité à celui qui est exigé par la plate-forme EE6, et de ce fait, les fonctionnalités EE7, tout comme les intercepteurs sur les points de terminaison, ne sont pas pris en charge.

Les RPM

Les packages Openjdk ne fournissent pas « java » dans les métadonnées

Plusieurs packages Openjdk (1.6.0, 1.7.0 et 1.8.0) ne fournissent pas de « java » dans les métadonnées des RPM, ce qui empêche la compatibilité avec des packages qui nécessitent Java et qui sont disponibles à partir du canal JBoss EAP. Pour contourner ce problème, installez un autre package fournissant « java » dans les métadonnées du RPM avant d'installer un des packages Openjdk ci-dessus.

Voir :

• https://bugzilla.redhat.com/show_bug.cgi?id=1189530
• https://bugzilla.redhat.com/show_bug.cgi?id=1189692
• https://bugzilla.redhat.com/show_bug.cgi?id=1189853
• https://bugzilla.redhat.com/show_bug.cgi?id=1189529

Console web

BZ#1180206 - Unable to unset wsdl-port and wsdl-secure-port if wrong value is entered first (impossible d'annuler la définition de wsdl-port et de wsdl-secure-port si une mauvaise saisie est entrée au départ)

Il n'est pas possible de changer les valeurs du port ou du port sécurisé des attributs WSDL en non défini par la console s'ils ont déjà une valeur définie. Les champs d'entrée pour ces attributs permettent actuellement uniquement des valeurs numériques et ne traitent pas une chaîne vide comme étant non définie.

Solution de contournement : pour retirer ces attributs, utiliser une des commandes suivantes dans l'interface CLI :

/subsystem=webservices:undefine-attribute(name=wsdl-port)

/subsystem=webservices:undefine-attribute(name=wsdl-secure-port)

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1180206

BZ#1014048 - RBAC: Log in right after log out wont clear UI properly in domain mode (se connecter juste après s'être déconnecté ne désactivera pas l'UI correctement en mode de domaine)

Dans certains cas, lorsque vous vous connectez à la console Web, la console est partiellement restituée avant de vous connecter en tant qu'autre utilisateur. Ceci conduit à un contenu « mixte » lorsque des parties de l'écran sont rendues comme si l'utilisateur précédent était connecté, et d'autres parties de l'écran, en fonction du nouvel utilisateur connecté.

Ce problème ne pose pas un risque pour la sécurité et aucune donnée sensible ne transpirera.

La solution de contournement à ce problème consiste à fermer la fenêtre du navigateur (pas uniquement l'onglet actif) et à se reconnecter en tant que nouvel utilisateur.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1014048

BZ#1027586 - RBAC: Web console is too coarse-grained with application resources (la console web a une granularité trop grossière pour les ressources d'application)

Dans cette version de JBoss EAP 6, lorsqu'une ressource est définie comme une ressource d'application, la console ne reflète pas cette définition. C'est parce que la console regroupe souvent plusieurs ressources sous une seule vue. Les contrôles sont disponibles dans les vues uniquement si toutes les ressources connexes sont accessibles en écriture. Si l'une de ces ressources est configurée comme une ressource d'application, alors, les contrôles connexes seront encore désactivés.

La solution actuelle est, si possible, de configurer tous les types de ressources associés à un sous-système en tant que ressource d'application.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1027586

JMS

BZ#1033008 - Generic JMS RA is not consistent with the EE spec - it does *not* ignore the parameters when session is created in the transaction context (le RA JMS standard n'est pas conforme à la spec EE - il n'ignore *pas* les paramètres quand une session est créée dans le contexte d'une transaction)

Cette version de JBoss EAP 6 comprend le problème suivant dans le composant JMS.

Quand une session est créée dans un contexte de transaction et que les paramètres sont passés à l'adaptateur de ressources JMS standard, une exception NullPointerException (NPE) a lieu.

Le problème se produit parce que l'on tente le traitement des paramètres alors que la spécification Java EE affirme qu'ils ne doivent pas être traités.

La cause principale du problème est à l'étude, mais d'ici là, la solution consiste à définir la session à traiter, comme dans l'exemple suivant. Avec cette solution de contournement, le NPE ne se produira pas.

connection.createSession(true, Session.SESSION_TRANSACTED);

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1033008

Sécurité

BZ#1103684 - Unable to share Identity Security Domain across datasources (impossible de partager le domaine de sécurité de l'identité à travers les sources de données)

Cette version de JBoss EAP 6 comporte un bogue qui présente l'erreur javax.resource.ResourceException: No matching credentials in Subject! (pas d'identifiants correspondants dans le sujet) lorsque plusieurs sources de données sont définies et soutenues par le même domaine de sécurité.

Ce problème est sous investigation et devrait être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1103684

BZ#1052644 - LdapExtLoginModule cannot find custom ldap socket factory (LdapExtLoginModule ne peut pas trouver d'usine de sockets ldap personnalisés)

Dans cette version de JBoss EAP 6, le module LdapExtLoginModule ne définit pas le TCCL au chargeur de classes d'un module de JBoss (configurable). Le module JBoss contiendrait une fabrique de sockets personnalisés.

De ce fait, le module LdapExtLoginModule utilise des fabriques de sockets personnalisés pour créer des connexions au server ldap. Une exception ClassNotFoundException sera lancée quand on tente d'utiliser une fabrique de sockets personnalisés avec le module LdapExtLoginModule.

Ce problème devra être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1052644

BZ#1145490 - FIPS 140-2 compliant mode doesn't work in JDK-8 (le mode conforme à FIPS 140-2 ne fonctionne pas dans JDK-8)

Cette version de JBoss EAP 6 contient le problème JDK8 suivant :

Lorsque vous utilisez un échange de clés RSA client par les protocoles SSL/TLS, le fournisseur SunJSSE ne peut pas fonctionner en mode de conformité FIPS 140. Cette question n'influe pas sur le mode par défaut de SunJSSE.

Vous pourrez trouver des informations supplémentaires à l'adresse suivante : http://www.oracle.com/technetwork/java/javase/8-known-issues-2157115.html

Gestion des domaines

BZ#1015524 - RBAC: unable to deploy the same deployment which was already deployed by user from different server-group scope (impossible de déployer le même déploiement s'il a déjà été déployé par un utilisateur d'un scope server-group différent)

Quand les contrôles d'accès basés rôle sont activés, les utilisateurs de gestion ayant des rôles server-group scoped peuvent avoir de nouveaux échecs de déploiement accompagnés du message suivant :

"JBAS014807: Management resource '[(\"deployment\" => \"example.war\")]' not found"

Cela se produit car un déploiement du même nom existe déjà dans le domaine. C'est un comportement correct. Cependant, parce que l'utilisateur de gestion s'étend à un groupe de serveurs, il n'est pas en mesure de voir si un tel déploiement existe déjà dans un autre groupe de serveurs. Il est donc difficile d'éviter cette erreur déroutante.

Pour contourner cette limitation, Red Hat recommande que les non-scoped roles soient assignés aux utilisateurs chargés d'ajouter des déploiements à un domaine, ou qu'une liste de noms de déploiement soit maintenue afin que les utilisateurs de gestion en soient conscients.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1015524

BZ#1021607 - RBAC: The two kinds of non-addressability (les deux sortes de non-adressibilité)

Certaines ressources ne sont pas adressables au serveur-groupe et hébergent des scoped roles afin de fournir une vue simplifiée du modèle de gestion pour améliorer la facilité d'utilisation. Ce n'est pas la même chose que les ressources qui ne sont pas adressables dans le but de protéger des données sensibles.

Pour les rôles scoped server-group, cela signifie que les ressources dans les portions profile, socket binding group, deployment, deployment override, server group, server config et server du modèle de gestion ne seront pas rendues visibles aux server-groups spécifiés pour le rôle.

Pour les rôles host-scoped, cela signifie que des ressources dans la partie du modèle de gestion /host=* ne seront pas visibles si elles ne sont pas liées à des groupes de serveurs spécifiés pour le rôle.

Cependant, dans certains cas, cette vue simplifiée peut cacher des informations qui, si hors de portée du cadre de ce que l'utilisateur gère, peuvent amener l'utilisateur à une séquence d'actions. En voici un exemple BZ# 1015524.

Dans une prochaine version, certaines de ces ressources non adressables pourraient être modifiées pour être adressables, mais non lisibles. Cela n'affectera pas la sécurité du serveur parce qu'elles n'étaient pas adressables pour des raisons de sécurité. Red Hat recommande de ne pas compter sur la non-adressabilité des ressources pour cacher des informations, à moins que la non adressabilité soit définie dans une contrainte de sensibilité.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1021607

Clustering

BZ#917635 - Failed to load session: NullPointerException (n'a pas pu charger la session : NullPointerException)

Dans cette version, après le déploiement d'une application, dans certaines circonstances, on peut voir apparaître une exception NullPointerException avec le message « Impossible de charger la session ».

Ce problème devra être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=917635

BZ#959951 - CacheException: java.lang.RuntimeException: Failure to marshal argument(s) at server shutdown (n'a pas pu marshaler les argument(s) lors de la fermeture du serveur)

Au moment de la fermeture d'un serveur, le message suivant peut être enregistré :

CacheException: java.lang.RuntimeException: Failure to marshal argument(s) at server shutdown

Ce message se produit parce qu'Infinispan ne supporte pas encore l'arrêt simple et ce message peut donc être ignoré. Cette question est à l'étude, mais aucune solution de contournement connue n'est disponible actuellement.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=959951

BZ#901162 - TimeoutException: Unable to acquire lock (impossible d'obtenir un verrou)

Un problème connu dans cette version de JBoss EAP 6 entraîne l'envoi de l'exception TimeoutException: Unable to acquire lock (impossible d'acquérir le verrou) dans certaines circonstances.

Ce problème devra être résolu dans une version à venir.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=901162

BZ#900483 - Stale session data received when using DIST SYNC on jvm kill (données de session périmées quand on utilise DIST SYNC sur jvm kill)

Au cours des tests, certains cas ont montré que les données de session périmées étaient reçues lorsqu'un nœud s'arrêtait et que le mode de cache DIST SYNC ou DIST ASYNC étaient utilisés. Cette question est encore à l'étude.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=900483

BZ#900946 - IllegalStateException: Cache is in 'TERMINATED'/'STOPPING' state (le cache est dans l'état TERMINATED'/'STOPPING)

Cette version de JBoss EAP 6 comporte un bogue qui peut provoquer l'exception IllegalStateException à comparaître après qu'une demande soit annulée sur un seul nœud dans les 5 secondes après avoir été déployée sur un autre nœud du cluster.

Ce problème est sous investigation et devra être résolu dans une version à venir.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=900946

BZ#900378 - CDI beans with SET replication trigger are not replicating (les beans CDI avec des déclencheurs de réplication DÉFINIS ne sont pas répliqués)

En raison d'un bogue présent dans le composant Weld, la méthode setAttribute ne peut pas être appelée correctement. Cela entraîne les beans CDI ayant le déclencheur de réplication défini à la valeur SET à ne pas être répliqués.

La solution consiste à utiliser le déclencheur SET_AND_NON_PRIMITIVE_GET pour ces beans. Cela sera corrigé dans une version ultérieure.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=900378

BZ#922699 - IllegalStateException: AtomicMap stored under key X has been concurrently removed! (AtomicMap qui est stocké dans key X a été supprimé simultanément)

L'exception IllegalStateException peut être levée dans de rares cas, lorsque la routine de traitement de l'expiration et de passivation accède à une session qui est supprimée au même moment. Cela provoque une exception qui est journalisée.

L'exception peut être ignorée. Cependant, en désactivant la passivation de la sesssion, on est sûr que le problème sera évité.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=922699

Transaction Manager

BZ#1039081 - Please remove "path" and "relative-to" attributes from CLI (veuillez retirer les attributs "path" et "relative-to" de l'interface CLI)

En raison de la fonctionnalité non incluse dans JBoss EAP 6, les attributs path et relative-to n'ont aucune utilité dans le sous-système de transactions de l'interface CLI. Ces attributs sont devenus obsolètes dans cette version du produit et disparaîtront entièrement dans une version ultérieure.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1039081

JDR

BZ#917683 - Jdr utility generates wrong archive entry name running on Windows (l'utilitaire Jdr génère un nom d'archive erroné dans Windows)

On a trouvé un bogue dans l'utilitaire JDR lorsqu'il est utilisé dans les environnements Windows. Il a été signalé que l'utilitaire permet d'ajouter le dernier caractère du répertoire source $JBOSS_HOME au répertoire JBOSS_HOME créé à l'intérieur de l'archive.

Ainsi, pour un répertoire JBOSS_HOME d'origine nommé « jboss-eap-6.2 », l'utilitaire JDR produisait un répertoire d'archive nommé « JBOSS_HOME2 ».

La cause de ce bogue est toujours en cours d'investigation et il n'existe pas de solution pour l'éviter.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=917683

XML Frameworks

BZ#1065128 - Performance issue with Xalan transformer and very large text nodes (problème de performance avec le transformateur Xalan et noeuds de texte extra larges)

On a trouvé un bogue dans cette version de JBoss EAP 6 qui entraîne des problèmes de performance lorsque vous tentez de convertir des nœuds de texte volumineux à l'aide du transformateur Xalan. Lorsque vous utilisez le transformateur pour convertir un StreamSource en DOMResult, les performances du transformateur diminuent lorsque la taille des caractères de données augmente. C'est un problème connu qui sera corrigé dans une version ultérieure du produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1065128

CLI

BZ#1054874 - jboss-cli.sh cygwin support

Cette version de JBoss EAP 6 contient un bogue susceptible de causer des problèmes quand on utilise le produit dans un environnement Cygwin.

Les différences dans les implémentations de chemins d'accès POSIX et Microsoft Windows peuvent amener les variables des chemins d'accès dans le script de shell jboss-cli.sh à ne pas fonctionner comme prévu.

Ce problème devra être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1054874

Services web

BZ#1079049 - Problem using @SchemaValidation in combination with wsrm 1.1 (problème d'utilisation de @SchemaValidation en combinaison avec wsrm 1.1)

Si un client envoie un message de WS-RM 1.1 qui référence CreateSequence à un point de terminaison utilisant WS-RM ainsi que de la validation de schéma, l'application soulève l'erreur suivante :

Unmarshalling Error: cvc-elt.1: Impossible de trouver la déclaration de l'élément 'CreateSequence'.

On ne peut pas trouver CreateSequence dans fGrammerPool de org.apache.xerces.impl.xs.XMLSchemaLoader car CXF et JBossWS ne supportent pas encore WS-RM 1.1 totalement.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1079049

BZ#1074368 - Schema element generated from exception class doesn't honor @XmlElement annotation (Élément de schéma généré à partir d'une classe d'exception n'honore pas l'annotation @XmlElement)

On a trouvé un bogue dans cette version de JBoss EAP 6 qui cause un schéma généré à partir de classes d'exception à ne pas honnorer l'annotation @XmlElement. Ce problème sera résolu dans une prochaine version du produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1074368

mod_cluster

BZ#900047 - SystemMemoryUsageLoadMetric is not correct on Linux/Unix (SystemMemoryUsageLoadMetric n'est pas correct si utilisé dans Linux/Unix)

Le SystemMemoryUsageLoadMetric n'affiche pas d'informations utiles dans les systèmes d'exploitation Linux ou UNIX. Pour ces systèmes, HeapMemoryUsageLoadMetric procure des informations plus utiles. La solution à ce problème consistera à changer l'algorythme de SystemMemoryUsageLoadMetric pour qu'il soustraie la valeur du buffers/cache du nombre used. Le meilleur moyen de le faire est en cours d'investigation.

Le problème est à l'étude.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=900047

BZ#1085427 - StickySessions don't work for ProxyPass from unenabled context (les sessions sticky ne fonctionnent pas pour ProxyPass en provenance d'un contexte désactivé)

Cette version de JBoss EAP 6 comporte un bogue qui empêche les StickySessions de fonctionner avec ProxyPass en contexte activé. Ce problème devrait être résolu dans une prochaine version.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1085427

BZ#901170 - Apache with mod_cluster refuses to start (Apache refuse de démarrer si associé à mod_cluster) (manager.node)

Les clients ont signalé que dans les environnements Windows Server 2008 avec le UAC (User Account Control) activé, les fichiers et les répertoires requis pour mod_cluster ne sont pas créés.

Par conséquent, le processus httpd Apache ne démarre pas dans les installations de JBoss EAP 6 qui utilisent mod_cluster. L'erreur suivante a lieu :

[Tue Nov 06 07:55:18 2012] [emerg] create_mem_node C:/tmp/jboss-ews-2.0/var/cache/mod_cluster/manager.node failed: Access is denied.
Configuration Failed

Tandis que la désactivation UAC empêche ce problème de se produire, on a conclu que ce problème est provoqué par une erreur d'administration de Windows.

Si le chemin d'accès correct est défini dans MemManagerFile, la question ne se présentera que lorsque les autorisations utilisateur/service sont mal configurées.

Ce scénario peut probablement se produire dans les environnements de domaine contrôlé quand l'administrateur de domaine doit accorder des autorisations de domaine appropriées afin que l'UAC ne considère pas le MemManagerFile comme une menace.

Aucune action supplémentaire ne sera prise à propos de ce problème.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=901170

RESTEasy

BZ#899664 - RESTEasy: Boolean configuration parameters don't reject non-sense content (les paramètres de configuration booléenne ne rejètent pas le contenu dépourvu de sens)

Cette version de JBoss EAP 6 comporte un bogue qui permet la configuration de paramètres booléens non valides. Ce comportement n'est pas voulu car les paramètres non valides devraient être rejetés et l'application devrait être déployée.

Ce problème devra être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=899664

JCA

BZ#1184610 - Race condition registering resource adapters at startup (condition de concurrence enregistrant les adaptateurs de ressources au démarrage)

Cette version de JBoss EAP contient une condition de concurrence lors de l'inscription des adaptateurs de ressources quand plusieurs threads peuvent tenter de créer le sous-système d'adaptateurs de ressources.

Lorsque plusieurs adaptateurs de ressources ont été définis, deux ou plusieurs threads peuvent essayer de créer le sous-système d'adaptateurs de ressources en mémoire (par exemple lors du démarrage du serveur). Un seul thread peut effectuer cette tâche correctement. Les autres threads échoueront, en laissant un ou plusieurs adaptateurs de ressources dans un état « non déployé ».

Ce problème devra être résolu dans une version à venir de ce produit.

Voir http://bugzilla.redhat.com/show_bug.cgi?id=1184610

Compatibilité de mod_jk et de mod_cluster avec Apache dans RHEL 7

Le serveur Apache HTTP version 2.4.6, que l'on peut installer dans Red Hat Enterprise Linux 7, n'est pas pris en charge pour une utilisation avec mod_cluster et mod_jk fournis dans l'installationJBoss EAP 6 (soit en zip ou en RPM).

Pour pouvoir utiliser mod_cluster et/ou mod_jk, installer le serveur Apache HTTP (version 2.2.26) inclus dans JBoss EAP zip ou en distribution RPM.

mod_rt et mod_snmp

Les modules mod_rt (mod_rt.so) et mod_snmp (snmpmonagt.so) qui sont fournis dans la distribution Apache HTTP Server de JBoss EAP 6 ne sont pas pris en charge.

Vous trouverez davantage d'informations sur le support de ces modules dans la documentation Enterprise Web Server 2.1.

Le paramètre fail_on_status ne peut pas être utilisé avec HP-UX v11.3 hpws httpd B.2.2.15.15.

Le paramètre ProxyPass fail_on_status n'est pas fourni dans le HP-UX v11.3 hpws httpd B.2.2.15.15 Apache HTTP Server publié par HP. De ce fait, le paramètre ne peut pas être utilisé avec les implémentations mod_cluster par ce serveur HTTP.

Red Hat propose une version corrigée de httpd 2.2.15 dans Red Hat Enterprise Linux 6 qui prend en charge ce paramètre. Pour en savoir plus sur cette correction : http://pkgs.devel.redhat.com/cgit/rpms/httpd/tree/httpd-2.2.15-proxy-failonstatus.patch?h=rhel-6.7&id=295e30e7413300d714cce1d983ecf25ec08ae17c

Protocole STOMP dans HornetQ

HornetQ bénéficie d'un support de la communauté pour le protocole STOMP. Ce protocole n'a pas été testé par Red Hat et n'est pas pris en charge par JBoss EAP.

Protocole REST dans HornetQ

HornetQ bénéficie d'un support de la communauté pour le protocole REST. Ce protocole n'a pas été testé par Red Hat et n'est pas pris en charge par JBoss EAP.

Les limitations IPv6 de JDK 6

Les limitations IPv6 suivantes sont causées par JDK 6, et ne sont pas des défectuosités de JBoss EAP 6.

• Dans le serveur Microsoft Windows, JDK 6 ne possède uniquement qu'une implémentation partielle de IPv6. Cette implémentation n'est pas suffisante pour exécuter JBoss EAP 6. Un support complet d'IPv6 sur Microsoft Windows Server requiert JDK 7.
• Sur Red Hat Enterprise Linux, un bogue dans Oracle JDK 6 signifie que n'importe quelle adresse spécifiée sur un client (le point de réseau établissant la connexion) contenant un id de zone échouera. Pour utiliser un id de zone, il vous faudra soit passer à JDK 7, soit utiliser IcedTea/OpenJDK 6, qui est disponible dans Red Hat Enterprise Linux et ne présente pas ce bogue. Pour plus d'informations sur le bogue, reportez-vous à http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6800096 et https://issues.jboss.org/browse/JBPAPP-8833.

La propagation de contexte JPA 2.0 en dehors d'une transaction JTA

La propagation des contextes de persistance prolongés (XPC de l'anglais Extended Persistence Contexts) ne prenait pas en compte l'existence d'une transaction, avec les XPC qui continuaient d'être propagés. Ce comportement n'est pas conforme à la spécification JPA 2.0. La manipulation des XPC a été modifiée de façon à ce que lorsqu'il n'y a aucune transaction active, la propagation XPC est ignorée et le bean invoqué a son propre contexte de persistance au lieu du XPC.

Si votre application s'attend à ce que les contextes de persistance étendus soient propagés à l'extérieur des transactions JTA, vous devez vous demander si votre application doit être modifiée. Consultez le Guide de Migration de JBoss EAP 6 pour obtenir des instructions sur la mise à jour de votre application.

JBoss Enterprise Application Platform 5 fournit une propriété système (JBPAPP-923.alwaysPropagate) qui active ce comportement. Cette propriété système n'est pas disponible dans JBoss EAP 6.

Pour obtenir plus d'informations sur cette décision, référez-vous à https://issues.jboss.org/browse/AS7-1663.

Les sous-systèmes de gestion PicketLink

Les sous-systèmes de gestion PicketLink Identity Management et Federation ne sont pas pris en charge dans JBoss EAP 6.

Mise en pool de clients STS

Le sous-système Federation de PicketLink fournit un groupe de clients STS sur le serveur. Cela retire la création de clients STS comme goulot d'étranglement.

La mise en pool de clients peut être utilisée par des modules de connexion qui ont besoin d'un client STS pour obtenir des tickets de SAML.

Modules de connexion qui peuvent utiliser une mise en pool de clients STS :

• org.picketlink.identity.federation.core.wstrust.auth.STSIssuingLoginModule
• org.picketlink.identity.federation.core.wstrust.auth.STSValidatingLoginModule
• org.picketlink.trust.jbossws.jaas.JBWSTokenIssuingLoginModule

Le nombre de client dans le pool pour chaque module de connexion par défaut est configuré par l'option de module de connexion initialNumberOfClients.

Le classe STSClientPoolFactory org.picketlink.identity.federation.bindings.stspool.STSClientPoolFactory fournit une fonctionnalité de mise en pool de clients aux applications.

Utilisation de STSClientPoolFactory

Les clients STS sont insérés dans des sous-pool en utilisant comme clé configuration. Obtenez une instance de STSClientPool et initialiser un sous-pool sur la base de la configuration, avec le nombre de clients STS initiaux en option, ou bien basez-vous sur le nombre par défaut.

final STSClientPool pool = STSClientPoolFactory.getPoolInstance();
pool.createPool(20, stsClientConfig);
final STSClient client = pool.getClient(stsClientConfig);

Quand vous aurez terminé avec un client, vous pouvez le renvoyer au pool de la manière suivante :

pool.returnClient();

Pour vérifier si un sous-pool existe déjà pour une configuration donnée :

if (! pool.configExists(stsClientConfig) {  
    pool.createPool(stsClientConfig);  
}

Lorsque le sous-système PicketLink Federation est activé, toutes les pools de client créés pour un déploiement sont détruits automatiquement pendant le processus d'annulation du déploiement. Pour détruire un pool manuellement  :

pool.destroyPool(stsClientConfig);

Tanuki Service Wrapper

Le Tanuki Service Wrapper n'est pas pris en charge dans JBoss EAP 6. Vous trouverez plus d'informations dans https://issues.jboss.org/browse/JBPAPP-8651.

XA Recovery dans Microsoft SQL Server 2008

XA Recovery ne fonctionne pas dans Microsoft SQL Server 2008 R1. XA Recovery fonctionne dans Microsoft SQL Server 2008 R2 SP2. Pour plus d'informations, reportez-vous aux URL suivants  :

• https://issues.jboss.org/browse/JBPAPP-8983
• https://bugzilla.redhat.com/show_bug.cgi?id=901254
• https://community.jboss.org/thread/145358

XA Recovery dans MySQL

Le pilote JDBC MySQL n'implémente pas correctement le recouvrement XA et retourne des codes d'erreur incorrects pour les exceptions lorsque la connexion à la base de données est interrompue.

Pour obtenir plus d'informations, veuillez consulter https://issues.jboss.org/browse/JBPAPP-2576 et http://bugs.mysql.com/bug.php?id=72890

JBoss OSGi

JBoss OSGi, une implémentation de la spécification OSGi, a été rétrogradé de statut Aperçu technologique à Non pris en charge. Pour plus d'informations, reportez-vous à https://access.redhat.com/site/solutions/362814.

Quickstarts

Un certain nombre de quickstarts (helloworld-osgi, wicket-war et wicket-ear) qui étaient disponibles dans JBoss EAP 6.2, ont été supprimés du produit lors de la sortie 6.3 et ne sont toujours pas disponibles dans 6.4.

PicketLink

L'IDM (Identity Management) de PicketLink n'est pas pris en charge dans JBoss EAP 6.

API Infinispan

L'utilisation directe de l'API Infinispan n'est pas supportée dans JBoss EAP 6. Infinispan est utilisé comme un détail d'implémentation dans diverses technologies de clusters internes à JBoss EAP 6. L'utilisation directe de l'API Infinispan nécessite un abonnement à Red Hat JBoss Data Grid et l'installation de packages de JBoss Data Grid. Le téléchargement Red Hat JBoss Data Grid est disponible à l'adresse suivante https://access.redhat.com/downloads.