3. Problèmes connus et résolus

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)

Copy to Clipboard Toggle word wrap

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

Copy to Clipboard Toggle word wrap

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)

Copy to Clipboard Toggle word wrap

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

Copy to Clipboard Toggle word wrap

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.

Copy to Clipboard Toggle word wrap

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: ????????????

Copy to Clipboard Toggle word wrap

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>

Copy to Clipboard Toggle word wrap

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

Copy to Clipboard Toggle word wrap

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