Changements de comportement dans Contexts and Dependency Injection d'une édition à l'autre
Avec les changements de comportement présents dans l'implémentation Contexts and Dependency Injection (CDI) 1.2, une application ayant été migrée à partir de CDI 1.0 peut se comporter différemment ou échouer sur 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 changements 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.
Migration de CDI 1.0 vers CDI 1.2
Dans l'implémentation CDI 1.0, le CID est unique au niveau global. Dans CDI 1.2, il est unique pour chaque 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.
- Dans une implémentation CDI 1.2, l'exemple suivant illustre un schéma qui est référencé dans le fichier beans.xml :
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.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"
L'implémentation CDI 1.2 définit deux types d'archives de bean différents : explicite et implicite
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 beans de session. Voir la spécification Contexts and Dependency Injection for the Java EE platform.
Lorsque le schéma est mis à jour vers une implémentation CDI 1.2, pour que l'archive de bean reste définie comme explicite, le mode de détection de bean doit avoir pour valeur 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 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é enableImplicitBeanArchives au fichier server.xml pour votre serveur Liberty :
En définissant cette propriété sur false, vous évitez que les archives sans fichier beans.xml ne deviennent des archives de bean implicites.<cdi12 enableImplicitBeanArchives="false"/>
Si cette propriété est définie sur false, les performances sont améliorées au démarrage.