Changements de comportement dans Contexts and Dependency Injection 1.2

L'implémentation Contexts and Dependency Injection (CDI) 1.2 contient des changements de comportement qui peuvent provoquer qu'une application ayant migré depuis CDI 1.0 se comporte différemment ou échoue sous CDI 1.2.

Vous pouvez choisir entre les implémentations des fonctions CDI 1.0 et CDI 1.2 pour chaque instance de serveur, mais vous devez tenir compte des changements de comportement. Si le comportement désiré est uniquement contenu dans la fonction CDI 1.2, vous devez utiliser la fonction CDI 1.2. Si des modifications de comportement de la fonction CDI 1.2 peuvent avoir une incidence négative sur une application existante, l'utilisation de la fonction CDI 1.0 peut pérenniser le comportement existant pour cette application. Il n'est pas possible d'utiliser à la fois les fonctions CDI 1.0 et les fonctions CDI 1.2 dans le même serveur car les fonctions ne sont pas compatibles. Si vous configurez les deux fonctions, le serveur générera une erreur de configuration.

La fonction CDI 1.0 repose sur l'implémentation Apache OpenWebBeans de CDI. La fonction CDI 1.2 repose sur l'implémentation Weld de CDI. Les changements de comportement ont été introduits en raison des différences entre les deux implémentations.

CID de l'ID de conversation

Dans l'implémentation CDI 1.0, le CID est unique au niveau global. Dans CDI 1.2, il est unique par session HTTP. Ce comportement est en ligne avec la spécification CDI et correspond à la convention choisie par le Weld. Pour obtenir un CID unique à niveau global, le CID doit être spécifié au début de la conversation en appelant Conversation.begin.

Référencement des schémas dans le fichier beans.xml

L'exemple suivant montre un schéma référencé dans le fichier beans.xml, dans l'implémentation CDI 1.2 :
xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
Si vous utilisez un schéma non valide, le serveur produit une erreur d'exception. Vous pouvez désactiver la validation du fichier beans.xml en définissant la propriété JVM org.jboss.weld.xml.disableValidating=true, qui permet également d'éviter cette erreur. Si le fichier beans.xml spécifie des décorateurs ou des intercepteurs, un schéma valide doit être utilisé, sinon les décorateurs et les intercepteurs ne sont pas instanciés correctement.

Archives de bean implicites

L'implémentation CDI 1.2 définit deux types différents d'archives de bean : les archives explicites et les archives implicites.

Une archive de bean explicite est une archive qui contient un fichier beans.xml :
  • avec un numéro de version de 1.1 (ou ultérieur) et avec le mode de détection de bean all
  • sans numéro de version
  • qui est un fichier vide

Une archive de bean implicite est tout autre archive contenant une ou plusieurs classes de bean avec une annotation de définition de bean (comme défini dans la section 2.5.1 "Bean defining annotations" de la spécification) ou un ou plusieurs bean de session. Voir la spécification : Contexts and Dependency Injection for the Java™ EE platform.

Lorsque le schéma est mis à jour à une implémentation CDI 1.2, pour conserver l'archive de bean comme explicite, le mode de détection de bean doit être défini sur all :
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="all"
		version="1.1">
Remarque : Une archive de bean implicite détecte uniquement les bean ayant une annotation de définition de bean.
Ce nouveau type d'archive de bean peut donner pour résultat une archive qui n'est pas destinée à être une archive de bean CDI mais qui devient une archive de bean implicite dans l'implémentation CDI 1.2. Pour arrêter ce comportement, vous pouvez ajouter un fichier beans.xml avec le mode de détection de bean défini sur none, afin d'éviter que l'archive ne devienne une archive de bean. Une autre solution consiste à ajouter la propriété suivante au fichier server.xml pour votre serveur Liberty :
<cdi12 enableImplicitBeanArchives="false"/>
En définissant cette propriété sur false, vous évitez que les archives sans fichier beans.xml ne deviennent des archives de bean implicites.

Si cette propriété est définie sur false, les performances sont améliorées au démarrage.


Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_cdi_behavior.html