Discussion :

[IDtalc]

bonjour,

je traine une incompréhension concernant les attributs des beans managés. Certains de leurs attributs doivent être injectés avec l'annotation @EJB, et d'autres non !
Au départ, je pensais que @EJB s'imposait lorsque l'attribut était un objet d'une classe "maison" ...mais visiblement ce n'est pas tout à fait ça.
A cette heure, je nourrie l'idée que cela concerne les attributs-object dont la classe hérite d'une classe "maison" ...
Alors, avant de nourrir toutes les idées de la terre, je fais appel à vos lumières : quelle est la règle ?

[tchize_]

@EJB sert à injecter un EJB. Ni plus ni moins.

[IDtalc]

@EJB sert à injecter un EJB. Ni plus ni moins.

alors ma question est mal formulée. Je fais une autre tentative :
Qu'est-ce qui détermine si tel ou tel attribut doit être un EJB ?

[fr1man]

Un EJB permet entre autre, d'ajouter la gestion des transactions, la sécurité, la possibilité de garder un état entre deux requêtes dans le cas d'un statefull, faire de l'asynchrone à partir d'une file de message JMS dans le cas de message bean, etc...

[tchize_]

Qu'est-ce qui détermine si tel ou tel attribut doit être un EJB ?

Ce n'est pas l'attribut qui détermine si cela doit être un EJB, c'est l'EJB en lui même. L'attribut ne fait que suivre le fait que ce soit un EJB et que donc il faut l'injecter comme tel.

Ce dont bénéficie un EJB en gros dont ne bénéficient pas les beans CDI:
Toutes les annotations de securité et de transaction
Peut être exporté pour être accessible à distance
Possibilité de brancher des intercepteurs
Reception des messages JMS (message driven beans)
Propagation de sécurité inter domaine
Méthodes asynchrones
Pooling

Si tu n'a pas besoin de ça, tu peux te contenter d'un bean CDI.

[IDtalc]

bien le bonjour,

merci à vous deux. Je reste cependant encore dans le flou. Il est fort possible que l'information que je cherche figure déjà parmi vos réponses, mais que je ne sache pas la lire.
Déballage de ce que je crois avoir compris : l'annotation @ManagedBean me permet de préserver l'objet coté serveur entre deux requêtes d'un même client.
En gros, ça indique à la JVM du serveur : "ne delete pas trop vite cette d'instance, on risque d'en avoir besoin par la suite". Du coup, il lui faut aussi garder en mémoire les attributs ...et c'est là qu'intervient l'annotation @EJB ...mais uniquement dans des cas bien précis ! C'est sur ce point que la précision me manque.

Prenons un exemple simple (qui fonctionne) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
@SessionScoped
@ManagedBean
public class BeanVoiture {
 
	private Voiture uneVoiture;
	@EJB  
	private DaoVoiture daoVoiture;
 
	public BeanVoiture (){
		uneVoiture= new Voiture();	
	}
	...

Puisqu'on n'a pas besoin d'injecter uneVoiture, pourquoi doit-on injecter daoVoiture ?
Serait-ce parce que toutes les instances de BeanVoiture (une par client) doivent se partager une seule et unique instance de daoVoiture ?
...ou encore que les instances de BeanVoiture ne doivent pas utiliser leur daoVoiture au même moment ?
ça ressemble fortement à une espèce de stratégie pour gérer les conflits de CRUD, car la seule distinction intéressante entre ces deux objets, selon moi, c'est l'accès à la table "voitures" de daoVoiture.
J'ai grand besoin d'être fixé pour de bon ; vous comprenez que je ne peux pas rester dans cette ignorance plus longtemps.
(ne pas avoir le niveau en anglais, pour la prog, c'est un sacré handicap)

[fr1man]

J'imagine que ton objet Voiture est un simple JavaBean.
Tu gères toi même sa création dans le constructeur de ton BeanVoiture.
Dans le cas d'une ressource injectée comme DaoVoiture, c'est ton serveur d'application qui gère cet aspect.
En interne ton serveur possède un pool d'EJB DaoVoiture (que tu peux configurer), donc des instances déjà créées et prêtes à être injecter.
Un EJB est un objet complexe donc plus lourd à construire.

Le fait que ton ManagedBean survive entre deux requêtes est du à l'annotation SessionScope plutôt qu'à l'annotation ManagedBean.
Change ton bean en RequestScope et tu auras perdu le contexte entre deux requêtes.

[tchize_]

l'annotation @ManagedBean me permet de préserver l'objet coté serveur entre deux requêtes d'un même client.

Non, l'annotation @ManagedBean signifie à CDI qu'il doit gérer le cycle de vie de ta classe.

Du coup, il lui faut aussi garder en mémoire les attributs ...et c'est là qu'intervient l'annotation @EJB

Non, l'annotation @EJB dit à CDI "quand tu crée BeanVoiture, il a besoin d'avoir accès à l'EJB DaoVoiture

Puisqu'on n'a pas besoin d'injecter uneVoiture, pourquoi doit-on injecter daoVoiture ?

On a pas "besoin" de l'injecter. C'est juste que c'est plus facile de l'injecter que d'aller rechecher à la main l'EJB dans le JNDI. Ca permet aussi de s'assurer que l'EJB est rendu au pool lorsque le ManagedBean en a fini avec lui.

daovoiture est un EJB, il a besoin de toutes l'infrastructure EJB pour fonctionner (sinon on n'en ferait pas un EJB). Tu ne peux donc pas faire simplement un new dessus puisque cette instance serait hors infrastructure. Duc oup il faut demander poliment au constructeur une instance de l'EJB. Tu peux le faire via le JNDI en utilisant le nom complet de l'EJB, ou via l'annotation @EJB sur l'attribut, à condition que tu dois dans une classe elle même gérée par le conteneur.