Que fait l'annotation @EJBs?

je sais à peu près ce que fait cette construction: elle crée une EJB de type Somet et injecte l'objet dans une autre EJB.

 @EJB(name="name1")
 SomeType someVariable

maintenant j'ai une classe qui commence comme ceci: (je donne toutes les annotations au niveau de la classe, même si je pense que seulement le @EJBs est pertinent)

@Remote(SomeClass.class)
@Stateless(name="someName")
@EJBs({@EJB(name="name1",beanInterface=Type1.class),
       @EJB(name="name2",beanInterface=Type2.class)})
@TransactionAttribute(TransactionAttributeType.REQUIRED)
@TransactionManagement(TransactionManagementType.CONTAINER)
public class X extends Y{ 
  //code

Ce qui ne l' @EJB s font ici? Ils obtiennent probablement ou créent le "name1" ... objets de JNDI, mais où mettent-ils le résultat? Je ne vois pas .lookup appeler n'importe où près, mais le codebase est énorme donc je ne suis pas très sûr.

question Bonus: je présume que les deux @Transaction annotations il suffit de répéter les valeurs par défaut?

mise à jour: Plusieurs personnes revendiqué à ce point que @EJBs est une extension propriétaire. Il n'est pas. C'est une partie centrale de java EE5. Voir le JavaDoc pour plus de détails.. C'est simplement un conteneur pour l'individu @EJB annotations.

je crois que tous ceux qui revendiquent ces annotations EJB font Lookup. Je veux juste savoir ce qui se passe avec le résultat de cette recherche.

35
demandé sur hyperman 2012-09-10 13:12:09

4 réponses

@EJB annotation (et @Resource,@WebServiceRef, etc.) sert à deux fins:

  1. il déclare une référence dans l'espace de noms component. Par exemple, @EJB(name="myEJB") crée une référence java:comp/env/myEJB. Si vous annotez un champ et ne spécifiez pas de nom, alors il crée une référence java:comp/env/com.example.MyClass/myField.
  2. si l'annotation est déclarée sur une méthode de champ ou de setter, alors le conteneur effectue l'injection lorsque le composant est créé.

Comment l' de référence est résolu varie, indépendamment de si la référence est résolu lookup("java:comp/env/myEJB") ou en raison de l'injection:

  1. si EE 6+ est utilisé, le lookup attribut nécessite une recherche JNDI pour résoudre la cible.
  2. certains serveurs d'application prennent en charge mappedName, qui est spécifique au vendeur. C'est généralement mis en œuvre en effectuant une recherche.
  3. les serveurs D'Application prennent en charge les fixations au moment du déploiement. C'est généralement mis en œuvre par effectuez une recherche.
  4. si aucun autre renseignement contraignant n'est fourni et l'interface bean (beanInterface ou le type de champ) n'est implémenté que par une seule EJB dans l'application, alors la spécification EJB exige qu'il revienne à cela.
  5. si aucune autre information de liaison n'est fournie et #4 ne peut pas fonctionner, certains serveurs d'application tenteront d'effectuer une recherche dans l'espace de noms du serveur basé sur le nom ref (par exemple, java:comp/env/myEJB pourrait causer une recherche de myEJB dans l'espace de noms du serveur).
36
répondu Brett Kail 2012-09-12 14:09:52

la réponse de Miljen Mikic m'a donné une idée de la réponse possible. Si quelqu'un qui est au courant pour JNDI lit ceci, s'il vous plaît dites-moi si c'est sain, comme je le devine ici.

fondamentalement, il y a 2 façons de regarder dans l'arborescence JNDI: soit via un chemin global (/some/proprietary/path/my/bean) et via l'environnement de votre programme (java:comp/env/my/bean). L'idée est que vous créez des références à partir du Global path vers votre environnement local, et que vous y.

Donc @Ejb(name="java:comp/env/mon/bean",mappedName="/votre/exclusif/chemin/mon/bean") serait de créer cette référence à partir du code java (sans descripteur de fichier xml).

cela signifie que @Ejb (Nom="java: comp/env/my / bean") est en soi un no-op: il copie une référence sur lui-même. Il pourrait hava comme effet secondaire le fait que l'application serveur sait maintenant qu'au moment de la compilation que cette référence est nécessaire,mais c'est tout.

2
répondu hyperman 2012-09-12 07:51:32

selon ceci lien, essentiellement cette annotation permet à EJB de rechercher des EJB externes relativement à son contexte. Habituellement, il y a des façons plus élégantes de le faire.

1
répondu Miljen Mikic 2012-09-14 06:53:24

en ce qui concerne la question bonus: Oui, les deux annotations concernant les transactions se répètent par défaut: le type de transaction par défaut est CONTAINER (vs BEAN) et le - default - TransactionAttributeType requis indique simplement que si la bean est appelée dans un contexte transactionnel, la transaction est poursuivie, sinon une nouvelle transaction sera lancée (par opposition à, par exemple REQUIRES_NEW qui créera toujours un nouveau tx). C'est en fait dans le détail pas si trivial que cela sounds Cf. the EJB 3.1 spec:

"13.3.7 spécification des attributs de Transaction pour les méthodes D'un haricot

le Fève Fournisseur d'un fève d'entreprise avec la démarcation des transactions par conteneur peut préciser les attributs de transaction pour les méthodes du haricot d'entreprise. Par défaut, la valeur de la transaction attribut pour une méthode d'un haricot avec la démarcation de transaction de gestion de conteneur est le nécessaire attribut de transaction, et l'attribut de transaction n'est pas doivent être explicitement spécifiés dans ce cas.[...]"

1
répondu William Adams 2014-12-27 02:28:40