Bonjour,
Je possède en ce moment un code JEE 5 qui a à peu près cette structure:
La partie web contient des servlet et du Struts, ainsi que du JSF.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 ejb1-client.jar ejb1.jar ejb2-client.jar ejb2.jar web.war objetsMetiers1.jar objetsMetiers2.jar utilitaires1.jar
Dans mon EJB-client.jar se trouve:
@Remote public interface EJB1Remote extends EJB1
et @Local public interface EJB1Local extends EJB1
avec public interface EJB1 {méthodes exportées de l'EJB1Bean}
Une dernière classe, EJB1Facade, fait aujourd'hui les invocations à l'ancienne (InitialContext, setProperty() pour JNDI, lookup) et renvoie un objet de type EJB1 évitant à son appelant de savoir s'il reçoit un objet local ou remote.
Alors typiquement, aujourd'hui, j'ai dans mon ear:
application.xml =
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 <module><jar>objetsMetiers1.jar</jar></module> <module><jar>objetsMetiers2.jar</jar></module> <module><jar>utilitaires1.jar</jar></module> <module><ejb>ejb1.jar</ejb></module> <module><ejb>ejb2.jar</ejb></module> <module><war>web.war</war></module>
L'ensemble fonctionne parfaitement bien sous JBoss 5. J'ai décidé de le porter sous Glassfish v3 pour profiter de JEE 6 qui me semble très prometteur.
Alors, j'ai essayé de respecter quelques règles éparses que j'ai lues à droite et à gauche.
Par exemple, j'ai copié les fichiers jar dans un sous-répertoire lib de mon ear, comme j'ai appris que cela se faisait depuis JEE 5 pour les mettre à disposition de l'ensemble des éléments qui participent à mon ear.
1) N'y a t-il pas doublon entre mention dans application.xml et sa présence dans lib? Quelle est la différence d'interprétation entre les deux?
Ensuite, j'ai cherché à adapter mes invocations d'EJB. En restant tout d'abord sur le principe du InitialContext/JNDI.properties/lookup. Mais j'ai rencontré des NamingException en pagaille.
En particulier, Glassfish semble avoir des entrées JNDI de la forme:
<ear>/<jar déployé>/<ejb> tel que: MonEAR/ejb1/EJB1Bean,
mais non seulement cette entrée dans l'annuaire je ne la joins pas mais de surcroit je ne comprends pas,
2) Quelle entrée dois-je rechercher dans l'annuaire pour demander a) un service Remote, b) un service Local? Comment se différencient-ils, côté JNDI?
J'ai aussi lu que je m'échinais pour rien. Que appserv-rt.jar avait déjà les réglages JNDI tout faits, et qu'il suffisait de s'en remettre à lui pour se passer entre-autres, des setProperty initiaux associés à l'InitialContext.
Oui mais, si je le mets dans mon ear, son MANIFEST.MF réclame que ../modules/gf-client.jar s'y trouve aussi, et ce dernier mentionne lui-même tant d'autres jars que le suivre revient à intégrer tout le répertoires modules de Glassfish, pour un ear atteignant 40 Mo...
Il est évident que je fais fausse route.
3) Dois-je mentionner appserv-rt.jar quelque-part dans l'ear ou non? Et comment?
Mais baste que tout cela. De nos jours tout doit se régler par une invocation @EJB. Cela se lit partout. D'autant que la portée de cette annotation se serait accrue en JEE 6. Et qu'elle serait capable de permettre son emploi quelque soit le container.
Humm..., dans les faits:
4) Vais-je pouvoir utiliser @EJB tout à la fois: a) au sein d'un autre EJB, b) depuis une servlet, c) dans une page jsp, d) dans une page web jsf, e) dans un objet Action de Struts?
Je sais que l'emploi de @EJB fait appel à de l'injection de dépendance, mais je la maîtrise peu.
5) Quelle est la manière la plus simple et la plus propre que vous connaissez de mettre en oeuvre cette injection de dépendance dans JEE 6?
6) Puis-je escompter en JEE 6 supprimer toutes mes invocations EJB "à l'ancienne" pour n'en passer plus que par cette annotation @EJB?
En vous remerciant pour toute les connaissances que vous avez sur n'importe lequel de ces points. Chaque information, même parcellaire, me sera très utile pour avoir une vue globale et me permettre un bon portage.
Grunt.
Partager