Chapitre 5. Changements apportés à la migration des applications

JBossWS 5 apporte de nouvelles fonctionnalités et améliorations des performances aux services web JBoss EAP 7, principalement à travers la mise à niveau des composants Apache CXF, Apache WSS4J, et Apache Santuario.

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointImpl</config-name>
    <property>
      <property-name>cxf.interceptors.in</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointInterceptor,org.jboss.test.ws.jaxws.cxf.interceptors.FooInterceptor</property-value>
    </property>
    <property>
      <property-name>cxf.interceptors.out</property-name>
      <property-value>org.jboss.test.ws.jaxws.cxf.interceptors.EndpointCounterInterceptor</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:javaee="http://java.sun.com/xml/ns/javaee"
  xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
  <endpoint-config>
    <config-name>Custom FI Config</config-name>
    <property>
      <property-name>cxf.features</property-name>
      <property-value>org.apache.cxf.feature.FastInfosetFeature</property-value>
    </property>
  </endpoint-config>
</jaxws-config>

import org.apache.cxf.frontend.ClientProxy;
import org.apache.cxf.transport.http.HTTPConduit;
import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;

// Set chunking threshold before using a JAX-WS port client
...
HTTPConduit conduit = (HTTPConduit)ClientProxy.getClient(port).getConduit();
HTTPClientPolicy client = conduit.getClient();

client.setChunkingThreshold(8192);
...

Dans JBoss EAP 7, le connecteur par défaut a changé de remote à http-remoting et le port de connexion à distance par défaut est passé de 4447 à 8080. L'URL du fournisseur JNDI pour la configuration par défaut est passé de remote://localhost:4447 à http-remoting://localhost:8080.

Si vous utilisez l'opération migrate de JBoss EAP 7 pour mettre à jour votre configuration, vous n'aurez pas besoin de modifier le connecteur distant, ni le port distant ou l'URL de fournisseur JNDI parce que l'opération de migration préservera les paramètres de configuration du connecteur distant et du port4447 dans la configuration du sous-système. Pour plus d'informations sur l'opération migrate, voir la Gestion des opération de migration par lignes de commande.

Si vous n'utilisez pas l'opération de migrate, et qu'à la place, vous exécutez avec la nouvelle configuration par défaut de JBoss EAP 7, vous devez modifier le connecteur distant, le port distant et l'URL de fournisseur JNDI pour utiliser les nouveaux paramètres, comme décrit ci-dessus.

La version précédente de JBoss EAP fournissait RESTEasy 2, qui est une implémentation de JAX-RS 1.x. JBoss EAP 7 comprend maintenant 3 RESTEasy, qui est une implémentation de JAX-RS 2.0 définie par la spécification JSR 339 : JAX-RS 2.0 : The Java API for RESTful Web Services. Pour plus d'informations sur l'API de Java des Services Web RESTful, consultez la Spécification de l'API JAX-RS 2.0.

La version de Jackson comprise dans JBoss EAP a changé. L'ancienne version de JBoss EAP comprenait Jackson 1.9.9. JBoss EAP 7 inclut maintenant Jackson 2.6.3 ou version supérieure.

Cette section décrit comment ces changements peuvent avoir un impact sur les applications qui utilisent RESTEasy ou JAX-RS.

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <exclusions>
      <module name="org.jboss.resteasy.resteasy-jackson2-provider"/>
      <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
    </exclusions>
    <dependencies>
      <module name="org.jboss.resteasy.resteasy-jettison-provider" services="import"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

JBoss EAP 7 inclut un support à CDI 1.2. De ce fait, les applications écrites avec CDI 1.0 risquent de voir des changements de comportement quand elles sont migrées dans JBoss EAP 7. Cette section résume quelques uns de ces changements uniquement.

Vous allez trouver des informations sur Weld et CDI 1.2 dans les références suivantes :

Archives Bean

Les classes de bean des beans activés doivent être déployées dans les archives de bean pour s'assurer qu'elles soient scannées par CDI afin de trouver et traiter les classes de bean.

Dans CDI 1.0, une archive était définie comme archive de beanexplicite si elle contenait un fichier beans.xml dans le répertoire META-INF/ pour une application cliente, un EJB, ou un JAR de bibliothèque, ou si elle contenait un fichier beans.xml dans le répertoire WEB-INF/ pour un WAR.

CDI 1.1 introduit des archives bean implicites, qui sont des archives qui contiennent une ou plusieurs classes de bean avec une annotation de définition de bean, ou une ou plusieurs session beans. Les archives bean implicites sont scannées par CDI et, au cours de la découverte du type, seules les classes ayant des annotations de définition de bean sont découvertes. Pour plus d'informations, consultez Type et Découverte de bean dans Injection de dépendances et contextes dans la plate-forme Java EE.

Une archive bean possède un mode de découverte de bean coorespondant à all, annoted ou none. Une archive bean qui contient un fichier beans.xml sans version dispose d'un mode de découverte de bean par défaut de all. Une archive de bean qui contient un fichier beans.xml avec la version 1.1 ou version ultérieure doit spécifier l'attribut bean-discovery-mode. La valeur par défaut de l'attribut est annoted.

Une archive n'est pas une archive bean dans les cas suivants :

Une archive est une archive bean explicite dans les cas suivants :

L'archive est une archive bean implicite dans les cas suivants :

CDI 1.2 limitait les annotations de définition de bean aux suivantes :

Pour plus d'informations sur les archives de bean, voir les Archives Bean dans Injection de dépendance et contextes dans la plateforme Java EE.

Clarification et Résolution de conversations

Le cycle de vie de contexte de conversation a été changé pour éviter tout conflit avec la spécification du Servlet comme décrit dans Problème de spécification CDI-411. Le scope de conversation est actif durant toutes les requêtes du servlet et ne devrait pas empêcher les autres servlets ou filtres de servlets de fixer le corps de la requête ou le codage de caractères.

Résolution par observation

La résolution de l'événement a été en partie réécrite dans CDI 1.2. Dans CDI 1.0, un événement est remis à une méthode d'observation si la méthode d'observation possède tous les qualificateurs d'événement. Dans CDI 1.2, un événement est remis à une méthode d'observation si la méthode d'observation n'a aucun qualificateur d'événement ou a un sous-ensemble de qualificateurs événement.

L'introduction du système de chargement de classe modulaire et des Modules JBoss dans la version précédente de JBoss EAP permet un contrôle très précis des classes disponibles aux applications. Cette fonctionnalité vous permet de configurer des dépendances de module explicites en utilisant le fichier MANIFEST.MF de l'application ou le fichier descripteur de déploiement jboss-deployment-structure.xml.

Si vous avez définit des dépendances de module explicites dans votre application, veuillez prendre en compte les changements suivants apportés à JBoss EAP 7.

Examiner les dépendances pour la disponibilité

Les modules inclus dans JBoss EAP ont changé. Lorsque vous migrez votre application vers JBoss EAP 7, veuillez examiner les entrées des fichiers MANIFEST.MF et jboss-deployment-structure.xml afin de vous assurer qu'elles ne font pas référence à des modules supprimés dans cette version du produit.

Dépendances requérant un scan d'annotations

Dans la version précédente de JBoss EAP, si votre dépendance contenait des annotations nécessitant d'être traitées pendant le scan des annotations, comme lors de la déclaration d'intercepteurs EJB, il est requis de générer et d'inclure un index Jandex dans un nouveau fichier JAR et de paramétrer un indicateur dans le fichier descripteur de déploiement MANIFEST.MF ou jboss-deployment-structure.xml.

JBoss EAP 7 permet désormais de générer un runtime automatique des index d'annotations pour les modules statiques, il n'est ainsi plus nécessaire de les générer manuellement. Cependant, vous devrez toujours ajouter l'indicateur annotations au fichier de l'application MANIFEST.MF ou au fichier descripteur de déploiement jboss-deployment-structure.xml comme indiqué ci-dessous.

Dépendances : com.company.my-ejb annotations, com.company.other

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name="com.company.my-ejb" annotations="true"/>
      <module name="com.company.other"/>
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Hibernate ORM 5.0

Si votre application contient un fichier persistence.xml ou si le code utilise les annotations @PersistenceContext ou @PersistenceUnit, JBoss EAP 7 les détectera pendant le déploiement et assumera que l'application utilise JPA. Les bibliothèques Hibernate ORM 5.O sont implicitement ajoutées (ainsi que quelques autres dépendances) au chemin de classe de votre application et ces bibliothèques sont utilisées par défaut.

Hibernate ORM 4.0 - 4.3

Si votre application nécessite que le cache du second niveau soit activé, vous devriez effectuer une migration vers Hibernate ORM 5.0, qui est intégré dans Infinispan 8.0.

Les applications écrites avec Hibernate ORM 4.x peuvent toujours utiliser Hibernate 4.x. Vous devez définir un module JBoss personnalisé pour les JAR Hibernate 4.x et exclure les classes Hibernate 5 de votre application. Cependant, il est fortement recommandé que vous ré-écriviez votre code d'application afin d'utiliser Hibernate 5.

Pour obtenir des informations sur les changements implémentés entre Hibernate 4 et Hibernate 5, veuillez consulter le Guide de migration Hibernate ORM 5.0.

Hibernate ORM 3.0

Les classes d'intégration qui ont facilité l'utilisation d'Hibernate 3 dans la version précédente ont été supprimées de JBoss EAP 7. Si votre application utilise toujours des bibliothues Hibernate 3, il est fortement recommandé de migrer votre application pour utiliser Hibernate 5 car Hibernate 3 ne fonctionnera plus dans JBoss EAP sans fournir de gros efforts. Si vous ne pouvez pas effectuer la migration vers Hibernate 5, vous devrez définir un module JBoss personnalisé pour les JAR Hibernate 3 et exclure les classes Hibernate 5 de votre application.

La version d'Hibernate Search comprise dans JBoss EAP 7 a changé. L'ancienne version de JBoss EAP comprenait Hibernate Search 4.6.x. JBoss EAP 7 inclut maintenant Hibernate Search 5.5.x.

Hibernate Search 5.5 repose sur Apache Lucene 5.3.1. Si vous utilisez des APIs Lucene natif, assurez-vous de vous aligner avec cette version. L' Hibernate Search 5.5 API encapsule et masque la complexité des nombreux changements des API Lucene qui ont eu lieu entre les versions 3 et 5. Cependant, certaines classes sont désormais déconseillées, renommées ou reconditionnées. Cette section décrit comment ces changements peuvent avoir une incidence sur votre code d'application.

Changements apportés au mappage dans Hibernate Search

Indexation des champs d'id dans les relations intégrées

Quand on utilise une annotation @IndexedEmbedded pour qu'elle puisse inclure des champs en provenance d'une entité liée, l'identifiant de l'entité liée n'est plus inclus. Vous pouvez activer l'inclusion de l'id en utilisant l'attribut includeEmbeddedObjectId de l'annotation @IndexedEmbedded.

@IndexedEmbedded(includeEmbeddedObjectId=true)

Modifications apportées au format d'indexes de dates ou de nombres

Les nombres et des dates sont maintenant indexés sous forme de champs numériques par défaut. Les propriétés de type int, long, float, double et leurs classes wrapper correspondantes ne sont plus indexées sous forme de chaînes. Au lieu de cela, elles sont désormais indexées en utilisant le codage numérique approprié de Lucene. Les champs d'identification (id) sont une exception à cette règle. Même quand ils sont représentés par un type numérique, ils sont toujours indexés comme un mot clé de chaîne par défaut. L'utilisation de @NumericField est désormais obsolète, sauf si vous voulez spécifier une précision personnalisée pour le codage numérique. Vous pouvez garder l'ancien format d'index basés sur une chaîne, en spécifiant explicitement un pont de champ de codage de chaîne. Dans le cas des entiers, c'est org.hibernate.search.bridge.builtin.IntegerBridge. Vérifier le paquet org.hibernate.search.bridge.builtin pour les autres ponts de champs accessibles publiquement.

Les champs Date et Calendrier ne sont plus indexés sous forme de chaînes. Au lieu de cela, les instances sont codées comme valeurs longues représentant le nombre de millisecondes depuis le 1er janvier 1970, 00:00:00 GMT. Vous pouvez changer le format d'indexation en utilisant le nouvel enum EncodingType. Par exemple :

@DateBridge(encoding=EncodingType.STRING)
@CalendarBridge(encoding=EncodingType.STRING)

Le changement de codage des dates et des nombres est important, et peut avoir un grand impact sur le comportement de l'application. Si vous avez une requête qui cible un champ qui avait été codé précédemment en chaîne, mais qui est maintenant codé numériquement, vous devez mettre la requête à jour. Les champs numériques doivent être recherchés par une requête NumericRangeQuery. Vous devez également vous assurer que tous les champs ciblés par facettage sont en codifiés par chaîne. Si vous utilisez la requête de DSL Search, la requête correcte devra être créée automatiquement pour vous.

Divers changements apportés à Hibernate Search

Classes d'Hibernate Search renommées ou re-paquetées

Voici un liste de classes d'Hibernate Search qui ont été renommées ou repaquetées.

Lucene - Classes renommées ou re-paquetées

Les analyseurs de demandes ont été déplacés dans un nouveau module, résultant en changement de packaging de org.apache.lucene.queryParser.QueryParser à org.apache.lucene.queryparser.classic.QueryParser.

Bon nombre des analyseurs Lucene ont été refactorisés, entraînant des modifications de packaging. Consultez la Documentation d'Apache Lucene pour trouver les paquets de remplacement.

Certaines classes d'utilitaire Apache Solr, par exemple TokenizerFactory ou TokenFilterFactory, ont été déplacés vers Apache Lucene. Si votre application utilise ces utilitaires ou des analyseurs personnalisés, vous devez trouver le nouveau nom du package dans Apache Lucene.

Voir Apache Lucene Migration Guide pour plus d'informations.

Les API d'Hibernate Search dépréciés

Pour obtenir une liste complète des interfaces d'Hibernate Search obsolètes, des classes, des enums, des types d'annotations, des méthodes, des constructeurs, et des constantes d'enum, voir Hibernate Search Deprecated API.

Interfaces d'Hibernate Search dépréciées

Classes d'Hibernate Search dépréciées

Enums dépréciés d'Hibernate Search

Annotations d'Hibernate Search dépréciées

Méthodes dépréciées d'Hibernate Search

Constructeurs d'Hibernate dépréciés

Changements ayant un impact sur les intégrateurs avancés

Cette section décrit les modifications qui ne font pas partie de l'API publique. Elles ne devraient pas influer le développeur moyen car ces artefacts devraient uniquement être accessibles par les intégrateurs qui étendent le framework d'Hibernate Search.

Le support aux beans d'entité EJB est facultatif dans Java EE 7 et les beans d'entité ne sont pas supportés dans JBoss EAP 7. Cela signifie que la persistance gérée par conteneur (CMP) (container-managed persistence) et que les beans entity (BMP) (bean-managed persistence ) doivent être réécrits pour utiliser des entités Java Persistence API (JPA) lors de la migration vers JBoss EAP 7.

Dans les versions précédentes de JBoss EAP, des beans d'entité étaient créés dans le code source de l'application en étendant la classe javax.ejb.EntityBean et en implémentant les méthodes requises. Ils étaient ensuite configurés dans le fichier ejb-jar.xml. Un bean d'entité CMP était spécifié en utilisant un élément <entity> qui contenait un élément enfant <persistence-type> avec une valeur de Conteneur. Un entity bean BPM a été spécifié avec un élément <entity> contenant un élément enfant <persistence-type> ayant une valeur de Bean.

Dans JBoss EAP 7, vous devez remplacer tout bean d'entité CMP et BMP dans votre code par des entités JPA (« Java Persistence API »). Les entités JPA sont créées en utilisant les classes javax.persistence.* et sont définies dans le fichier persistence.xml.

Ci-dessous figure un exemple de classe d'entité JPA.

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.Table;

@Entity
// User is a keyword in some SQL dialects!
@Table(name = "MyUsers")
public class MyUser {
    @Id
    @GeneratedValue
    private Long id;

    @Column(unique = true)
    private String username;
    private String firstName;
    private String lastName;

    public Long getId() {
        return id;
    }
    public String getUsername() {
        return username;
    }
    public void setUsername(String username) {
        this.username = username;
    }
    public String getFirstName() {
        return firstName;
    }
    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

Ci-dessous figure un exemple de fichier persistence.xml.

<persistence version="2.1"
      xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
  <persistence-unit name="my-unique-persistence-unit-name">
    <properties>
      // properties...
    </properties>
  </persistence-unit>
</persistence>

Pour obtenir des exemples d'entités JPA, voir les quickstarts bmt, cmt, et hibernate5 fournis dans JBoss EAP 7.

Une nouvelles propriété de persistance, jboss.as.jpa.deferdetach, a été ajoutée pour permettre la compatibilité avec le comportement de persistance présent dans les anciennes versions de JBoss EAP.

La propriété jboss.as.jpa.deferdetach contrôle si le contexte de persistance de transaction-scoped utilisé dans un thread de transaction non-JTA détache des entités chargées après chaque appel de l'EntityManager ou si il attend que le contexte de persistance soit fermé, par exemple, lors de l'invocation de bean de session se termine. La valeur de la propriété est par défaut sur false, ce qui signifie que des entités sont détachées ou effacées après chaque appel de l'EntityManager. C'est le comportement par défaut approprié ainsi défini dans la spécification JPA. Si la valeur de la propriété est définie sur true, les entités ne sont pas détachées tant que le contexte de persistance est fermé.

Dans JBoss EAP 5, la persistance se comportait comme si la propriété jboss.as.jpa.deferdetach était définie à la valeur true. Pour obtenir ce même comportement lors de la migration de votre application de JBoss EAP 5 à JBoss EAP 7, vous devez définir la valeur de la propriété jboss.as.jpa.deferdetach sur true dans votre persistence.xml comme illustré dans l'exemple suivant.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
    <persistence-unit name="EAP5_COMPAT_PU">
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>
    <properties>
         <property name="jboss.as.jpa.deferdetach" value="true" />
    </properties>
  </persistence-unit>
</persistence>

Dans JBoss EAP 6, la persistance se comportait comme si la propriété jboss.as.jpa.deferdetach était définie à la valeur false. C'est le même comportement que dans JBoss EAP 7, donc aucun changement n'est nécessaire quand vous migrez votre application.

Le connecteur distant et le port distant par défaut ont été modifiés dans JBoss EAP 7. Pour obtenir plus d'informations sur ce changement, voir Mise à jour du port et du connecteur d'URL distants.

Si vous avez utilisé l'opération migrate pour migrer la configuration de votre serveur, les anciens paramètres sont conservés et vous n'avez pas besoin d'ajouter les modifications détaillées ci-dessous. Toutefois, si vous exécutez avec la nouvelle configuration par défaut de JBoss EAP 7, vous devez ajouter les modifications suivantes.

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=remote://localhost:4447

java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
java.naming.provider.url=http-remoting://localhost:8080

La spécification du déploiement d'applications Java EE (JSR-88) visait à définir un contrat type pour activer les outils provenant de plusieurs fournisseurs pour configurer et déployer des applications sur n'importe quel produit de plateforme Java EE. Le contrat exigeait que les fournisseurs de produits Java EE implémentant les interfaces DeploymentManager et autres interfaces de javax.enterprise.deploy.spi puissent être accédées par les fournisseurs de l'outil. Dans le cas de JBoss EAP 6, un plan de déploiement est identifié par un descripteur XML nommé deployment-plan.xml qui est livré dans une archive ZIP ou JAR.

Cette spécification n'a été que faiblement adoptée car la plupart des produits de serveur d'application fournissent leurs propre solution de déploiement « riche en fonctionnalités ». Pour cette raison, la prise en charge de JSR-88 a été abandonnée sur Java EE 7, et par conséquent par JBoss EAP 7 aussi.

Si vous avez utilisé la JSR-88 pour déployer votre application, vous devez maintenant utiliser une autre méthode pour déployer l'application. La commande CLI de JBoss EAP deploy fournit un moyen standard de déployer des archives dans des serveurs autonomes ou dans des groupes de serveurs dans un domaine géré. Pour plus d'informations sur la gestion par interface en ligne de commandes (CLI), consultez le Guide de gestion en ligne de commandes.

Vous devez migrer manuellement les valves personnalisés ou des valves qui sont définies dans le fichier XML jboss-Web.xml. Cela inclut les valves créées en étendant la classe org.apache.catalina.valves.ValveBase et configurées dans l'élément <valve> du fichier descripteur jboss-Web.xml.

Migrer des valves configurées dans les déploiements

Dans JBoss EAP 6, vous pouvez définir des valves personnalisées au niveau de l'application en les configurant dans le fichier descripteur d'application web jboss-Web.xml. Dans JBoss EAP 7, il est possible de le faire avec les handlers d'Undertow également.

Voici un exemple de valve configurée dans le fichier jboss-web.xml de JBoss EAP 6.

<jboss-web>
    <valve>
        <class-name>org.jboss.examples.MyValve</class-name>
​        <param>
    ​        <param-name>myParam</param-name>
​            <param-value>foobar</param-value>
    ​    </param>
    </valve>
</jboss-web>

Pour obtenir plus d'informations sur la façon de créer et de configurer des handlers personnalisés dans JBoss EAP, voir Créer des handlers personnalisés du Guide de développement.

Migrer des valves d'authentificateur personnalisées

Pour obtenir plus d'informations sur la façon de migrer des valves d'authentificateur, voir Changements dans les applications de sécurité

Le remplacement de JBoss Web par Undertow nécessite des modifications de configuration de la sécurité dans JBoss EAP 7.

Si votre application utilise JBoss Logging, sachez que les annotations dans le paquet org.jboss.logging sont désormais dépréciées dans JBoss EAP 7. Elles ont été mises dans le paquet org.jboss.logging.annotations, donc vous devez mettre à jour votre code source pour importer le nouveau package.

Les annotations sont également passées à un numéro d'identification distinct (ID) pour Maven groupId:artifactId:version (GAV), donc vous devrez ajouter une nouvelle dépendance de projet à org.jboss.logging:jboss-logging-annotations dans votre fichier pom.xml du projet.

Le tableau suivant dresse la liste des classes d'annotations dépréciées et de leurs remplacements.

Support JSF 1.2 abandonné

JBoss EAP 6 vous permet de continuer à utiliser JSF 1.2 avec vos déploiemens d'applications en créant un fichier jboss-deployment-structure.xml.

JBoss EAP 7 inclut JSF 2.2 et ne supporte plus l'API JSF 1.2. Si votre application utilise JSF 1.2, vous devrez la réécrire pour utiliser JSF 2.2.

Problème de compatibilité entre JSF 2.1 et JSF 2.2

Les API JSF 2.1 et JSF 2.2 ne sont pas entièrement compatibles. La valeur de la constante FACELET_CONTEXT_KEY est passée de com.sun.faces.facelets.FACELET_CONTEXT à javax.faces.FACELET_CONTEXT entre les versions. Cette valeur est inlined par le compilateur et le code compilé pour une version ne fonctionnera pas avec l'autre.

Les applications qui contiennent du code similaire à l'exemple suivant et sont compilées avec l'API de JSF 2.1, mais qui sont exécutées dans JBoss EAP 7 en utilisant l'API JSF 2.2, engendrent une exception NullPointerException. Pour résoudre ce problème, vous devez recompiler l'application avec l'API JSF 2.2.

Object obj = FacesContext.getCurrentInstance().getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);

Voir JAVASERVERFACES_SPEC_PUBLIC-1257 pour plus d'informations.

Dans JBoss EAP 7, le comportement de chargement de classes a changé dans les cas où plusieurs modules contiennent les mêmes classes ou paquets.

Assumons qu'il y ait deux modules, MODULE_A et MODULE_B, dépendant l'un de l'autre et qui contiennent des paquets en commun. Dans JBoss EAP 6, les classes ou les paquets qui étaient chargés à partir des dépendances prévalaient sur ceux spécifiés dans ressource-root du fichier module.xml. Cela signifie que MODULE_A voyait les paquets pour MODULE_B et que MODULE_B voyait les paquets pour MODULE_A. Ce comportement a été source de confusion et pouvait entraîner des conflits. Il a changé dans JBoss EAP 7. Maintenant les classes ou les paquets spécifiés par ressource-root du fichier module.xml prévalent sur ceux qui sont spécifiés par la dépendance. Cela signifie que MODULE_A voit les paquets de MODULE_A et que MODULE_B voit les paquets de MODULE_B. Cela empêche les conflits et offre un comportement plus approprié.

Si vous avez défini des modules personnalisés avec des bibliothèques de ressources-root ou des paquets qui contiennent des classes dupliquées dans leurs dépendances de module, vous pouvez voir les exceptions ClassCastException, LinkageError, des erreurs de chargement de classes, ou autres changements dans le comportement de chargement lorsque vous migrez vers JBoss EAP 7. Pour résoudre ces problèmes, vous devez configurer votre fichier module.xml pour veiller à ce qu'une seule version de classe soit utilisée. Ceci peut être accompli en utilisant l'une des approches suivantes.

Si vous préférez conserver votre comportement existant, vous devez filtrer les paquets de dépendance par la ressource-root dépendante dans le fichier module.xml à l'aide de l'élément filter. Cela vous permet de conserver le comportement existant sans le bouclage singulier qui vous voyez dans JBoss EAP 6. Voici un exemple d'une ressource-root qui filtre les classes dans un package spécifié.

<resource-root path="mycompany.jar">
  <filter>
    <exclude path="com/mycompany/duplicateclassespath"/>
  </filter>
</resource-root>

Pour obtenir davantage d'informations sur les chargements de classes et les modules, voir Chargements de classes et modules dans le Guide de développement.