5. Fonctionnalités non prises en charge

Le serveur Apache HTTP que l'on peut installer dans Red Hat Enterprise Linux 7 via les canaux RHN introduit des problèmes de compatibilité avec mod_cluster et mod_jk, et il n'est pas pris en charge. Le serveur Apache HTTP fourni avec JBoss EAP, en revanche, est complètement pris en charge.

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.

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.

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.

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 à JBoss Data Grid.

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

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.

The PicketLink Management subsystems for IDP and Federation are not supported in JBoss EAP 6.3.

PicketLink fournit un pool de clients STS sur le serveur. Ainsi, la création de Client STS n'est plus source de goulot d'étranglement.

Le pooling client peut être utilisé par des modules de connexion qui ont besoin d'un client STS pour obtenir des tickets de SAML.

Modules de connexion qui peuvent utiliser un pooling de clients STS :

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 pool clients aux applications.

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 initial 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 votre client, vous pourrez le retourner au client 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 Fédération PicketLink 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);

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 ne fonctionne pas dans Microsoft SQL Server 2008 R1. Cette fonctionnalité fonctionne dans Microsoft SQL Server 2008 R2 SP2. Pour plus d'informations, reportez-vous aux URL suivants  :

Le pilote JDBC MySQL n'implémente pas correctement la récupération 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, 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.

Comme OSGi n'a jamais été pris en charge et a été retiré du produit, le quickstart helloworld-osgi a été supprimé dans les exemples fournis dans JBoss EAP 6.3.

Les quickstarts wicket-war et wicket-ear dépendent de seam-conversation-weld.jar. Comme Seam n'est pas pris en charge, ces quickstarts ont été retirés des exemples fournis dans JBoss EAP 6.3.