Résolution des haricots externes (3ème partie) dans la soudure

Question

Je sais qu'il est pas encore tout à fait populaire, puisque la spécification a été libéré il y a quelques mois.

Je ne l'ai pas « installé » encore soudure, je suis juste à lire, et par cette question que je veux vous assurer que je l'ai compris ce point important correct:

est la résolution des haricots qui sont dans des pots 3 parties réalisées par les déclarant comme <alternatives> dans votre beans.xml?

Dans le cas contraire, comment utiliser les haricots de bibliothèques 3ème partie qui n'ont pas beans.xml?

Mettre le pot sur le chemin de classe ne fonctionnera pas à moins d'beans.xml dans leur META-INF, que vous ne pouvez pas vrai pour les bocaux 3ème partie. (Voir le post Gavin King sur le sujet )

Answer 1

Pourquoi penser si compliqué?

Il suffit de faire un producerMethod pour les classes 3ème partie.

Supposons que vous avez une bibliothèque 3ème partie qui prend automatiquement les fichiers PDF et les envoie par faximile, et vous utiliser quelque chose comme

private @Inject PdfFaxService faxService;

dans votre code, vous pouvez alors simplement fournir ce une méthode de production. Le PdfFaxService fonctionne sans état, nous pouvons supposer que nous pouvons le faire @ApplicationScoped:

public @Produces @ApplicationScoped PdfFaxService createFaxService() {
  return new PdfFaxService(initparameters);
}

quelque part.

HTH.

Answer 2

Ma compréhension d'un autre est qu'il est une alternative à une autre implémentation d'une interface que vous pouvez utiliser dans un environnement de déploiement différent (par exemple un environnement de test). Une autre haricot est déclarée par annoter avec @Alternative.

Pour utiliser une alternative dans un scénario de déploiement donné, vous sélectionnez dans l'élément <alternatives> de votre descripteur de déploiement CDI META-INF/beans.xml. Cela permettra à des grains de @Alternative qui désactive par défaut.

Lorsqu'il est activé, si le conteneur trouve une dépendance ambiguë pour un point d'injection donné, il se penchera sur des solutions de rechange qui pourraient être injectés et, s'il y a exactement un, ramasser cette alternative.

En d'autres termes, alternatives sont une belle façon de remplacer un implémentation existante avec un autre au moment du déploiement. S'il n'y a rien à remplacer, vous n'avez pas besoin d'alternatives, il suffit de mettre votre pot sur le chemin de la classe. Je ne sais pas c'était exactement votre question cependant, j'ai un doute sur le concept de pots 3 parties.

Plus 2.1.4. Alternatives , 4.6. Alternatives et 4.7. Fixation dépendances non satisfaites et ambiguës (mais je suppose que c'est ce que vous lisez).

Mise à jour:. Pour répondre à votre question supplémentaire

  

Dans le cas contraire, comment utiliser les haricots de bibliothèques 3ème partie qui n'ont pas beans.xml

Cela ne peut pas se produire, une archive de haricot doit avoir un bean.xml (que ce soit vide) comme indiqué dans la section 15,6. Emballage et déploiement de la documentation:

  

CDI ne définit pas spécial   archives déploiement. Vous pouvez emballer   haricots dans JARs, EJB-JAR ou WARs-tout   emplacement de déploiement dans l'application   classpath. Cependant, les archives doit   une « archive haricot ». Cela signifie que chaque   archive contenant les haricots doivent   inclure un fichier nommé beans.xml dans le   répertoire META-INF du classpath ou   répertoire WEB-INF de la racine web (pour   archives WAR). Le fichier peut être vide.   Les haricots déployés dans les archives qui ne sont pas   un fichier beans.xml ne sera pas   disponible pour une utilisation dans l'application.

Ensuite, pour fixer une dépendance non satisfaite et ambiguë, reportez-vous à la section 4.7 a été mentionné précédemment.

Mise à jour 2: Il semble que l'utilisation BeforeBeanDiscovery.addAnnotatedType() il est possible d'ajouter d'autres classes à prendre en considération lors de la découverte de haricots. (BeforeBeanDiscovery est un événement)