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.
4 réponses
@EJB
annotation (et @Resource
,@WebServiceRef
, etc.) sert à deux fins:
- il déclare une référence dans l'espace de noms component. Par exemple,
@EJB(name="myEJB")
crée une référencejava:comp/env/myEJB
. Si vous annotez un champ et ne spécifiez pas de nom, alors il crée une référencejava:comp/env/com.example.MyClass/myField
. - 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:
- si EE 6+ est utilisé, le
lookup
attribut nécessite une recherche JNDI pour résoudre la cible. - 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. - 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.
- 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. - 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 demyEJB
dans l'espace de noms du serveur).
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.
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.
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.[...]"