[Glassfish v3] Portage JEE 5 vers 6. La meilleure construction ear et méthode d'invocation EJB possibles sont?

**grunt2000** · 16/04/2010, 13h11

Bonjour,

Je possède en ce moment un code JEE 5 qui a à peu près cette structure:

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

La partie web contient des servlet et du Struts, ainsi que du JSF.

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.

**alexismp** · 18/04/2010, 13h53

Difficile de tout couvrir, voici qq points néanmoins :

- il n'est pas recommandé de partager les définitions des interfaces distantes et locales. Sémantiquement elles sont différentes. L'implémentation implémente alors les deux interfaces :

Code :

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

1
2
3
@Stateless
public class NewSessionBean implements NewSessionBeanRemote, NewSessionBeanLocal {
...

Avec Java EE 6, il y a maintenant la notion de "portable global JNDI names" qui permet d'avoir le même nom JNDI dérivé de son nom et de son packaging dans tous les serveurs. Ce nom est affiché au moment du déploiement dans GlassFish v3 dans son log (domains/domain1/logs/server.log). Sinon tu peux utiliser asadmin pour obtenir la liste des entrées JNDI :

Code :

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

asadmin list-jndi-entries

D'une manière générale tu ne devrais que très rarement avoir besoin des noms JNDI si tu utilises @EJB (ou similaire dès Java EE 5) et @Inject avec Java EE 6. La FAQ EJB pour GlassFish a été mise à jour pour Java EE 6. Si tu utilises un client distant, il faudra bien entendu utiliser l'interface distante.

appserv-rt.jar ou gf-client.jar sont utiles pour les clients distants. Ce post sera peut-être utile.

Concernant les JARs, s'il s'agit de librairies externes (frameworks et autres), je te conseille de regarder du coté de l'option --libraries de "asadmin deploy".

@EJB est utilisable dans tout objet dont le cycle de vie est géré par le conteneur: EJB, servlet et JSF managed bean en Java EE 5 et managed bean et composant CDI en Java EE 6. Pas dans une action Struts par défaut donc.

La plupart des questions sont liées à JavaEE 5, pas vraiment à EE 6. Avec EE 6 @Inject semble pouvoir remplacer @EJB partout.

**Hanoni** · 02/11/2010, 12h25

Bonjour à tous,

il y a un point que j'ai du mal à saisir...

Avec Glassfish v3 et le fameux gf-client.jar dans le classpath de l'appli cliente, on n'a plus à se soucier du fichier jndi.properties ? C'est bien ça ou j'ai rien compris ?

Merci d'avance de votre réponse

**Elendhil** · 02/11/2010, 13h45

Oui c'est ça !

Cela marche qu'en local par contre avec gf-client.jar et faut pas déplacer le jar sinon les chemins qui pointent vers les autres jars ne seront plus valide.

En faite , elle est pratiquement vide cette archive , je pense que c'est surtout pour le manifeste:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
 
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: Apache Maven
Archiver-Version: Plexus Archiver
Built-By: java_re
Build-Jdk: 1.6.0_10
Package: org.glassfish.appclient.client.acc
Main-Class: org.glassfish.appclient.client.AppClientFacade
PreMain-Class: org.glassfish.appclient.client.acc.agent.AppClientConta
 inerAgent
Class-Path: ../modules/woodstox-osgi.jar ../modules/tools.jar ../modul
 es/glassfish-corba-asm.jar ../modules/glassfish-corba-codegen.jar ../
 modules/glassfish-corba-csiv2-idl.jar ../modules/glassfish-corba-newt
 imer.jar ../modules/glassfish-corba-omgapi.jar ../modules/glassfish-c
 orba-orb.jar ../modules/glassfish-corba-orbgeneric.jar ../modules/aut
 o-depends.jar ../modules/config.jar ../modules/config-types.jar ../mo
 dules/hk2.jar ../modules/hk2-core.jar ../modules/osgi-adapter.jar ../
 modules/tiger-types-osgi.jar ../modules/grizzly-comet.jar ../modules/
 grizzly-config.jar ../modules/grizzly-framework.jar ../modules/grizzl
 y-http.jar ../modules/grizzly-http-servlet.jar ../modules/grizzly-por
 tunif.jar ../modules/grizzly-rcm.jar ../modules/grizzly-utils.jar ../
 modules/pkg-client.jar ../modules/jaxb-osgi.jar ../modules/webservice
 s-osgi.jar ../modules/activation.jar ../modules/el-api.jar ../modules
 /mail.jar ../modules/endorsed/webservices-api-osgi.jar ../modules/end
 orsed/jaxb-api-osgi.jar ../modules/junit.jar ../modules/javax.persist
 ence.jar ../modules/org.eclipse.persistence.antlr.jar ../modules/org.
 eclipse.persistence.asm.jar ../modules/org.eclipse.persistence.core.j
 ar ../modules/org.eclipse.persistence.jpa.jar ../modules/org.eclipse.
 persistence.jpa.modelgen.jar ../modules/org.eclipse.persistence.oracl
 e.jar ../modules/bean-validator.jar ../modules/endorsed/javax.annotat
 ion.jar ../modules/javax.ejb.jar ../modules/javax.enterprise.deploy.j
 ar ../modules/javax.jms.jar ../modules/javax.management.j2ee.jar ../m
 odules/javax.resource.jar ../modules/javax.security.auth.message.jar 
 ../modules/javax.security.jacc.jar ../modules/javax.servlet.jar ../mo
 dules/javax.servlet.jsp.jar ../modules/javax.transaction.jar ../modul
 es/admin-core.jar ../modules/admin-util.jar ../modules/cli-framework.
 jar ../modules/config-api.jar ../modules/monitoring-core.jar ../modul
 es/acc-config.jar ../modules/gf-client-module.jar ../modules/amx-core
 .jar ../modules/amx-j2ee.jar ../modules/annotation-framework.jar ../m
 odules/common-util.jar ../modules/container-common.jar ../modules/gla
 ssfish-api.jar ../modules/glassfish-ee-api.jar ../modules/glassfish-n
 aming.jar ../modules/internal-api.jar ../modules/stats77.jar ../modul
 es/connectors-inbound-runtime.jar ../modules/connectors-internal-api.
 jar ../modules/connectors-runtime.jar ../modules/work-management.jar 
 ../modules/glassfish.jar ../modules/kernel.jar ../modules/deployment-
 common.jar ../modules/deployment-javaee-core.jar ../modules/dol.jar .
 ./modules/dtds.zip ../modules/schemas.zip ../modules/ejb-container.ja
 r ../modules/ejb-internal-api.jar ../modules/asm-all-repackaged.jar .
 ./modules/ldapbp-repackaged.jar ../modules/management-api.jar ../modu
 les/flashlight-agent.jar ../modules/flashlight-framework.jar ../modul
 es/gmbal.jar ../modules/jms-core.jar ../modules/orb-connector.jar ../
 modules/orb-iiop.jar ../modules/eclipselink-wrapper.pom ../modules/jp
 a-connector.jar ../modules/persistence-common.jar ../modules/cmp-inte
 rnal-api.jar ../modules/appclient.security.jar ../modules/ejb.securit
 y.jar ../modules/security.jar ../modules/websecurity.jar ../modules/w
 ebservices.security.jar ../modules/jta.jar ../modules/jts.jar ../modu
 les/transaction-internal-api.jar ../modules/el-impl.jar ../modules/js
 p-impl.jar ../modules/war-util.jar ../modules/web-cli.jar ../modules/
 web-core.jar ../modules/web-glue.jar ../modules/web-gui-plugin-common
 .jar ../modules/web-naming.jar ../modules/jsr109-impl.jar ../modules/
 mimepull.jar ../../mq/lib/imq.jar ../../mq/lib/imqadmin.jar ../../mq/
 lib/imqutil.jar ../../mq/lib/fscontext.jar ../lib/install/application
 s/jmsra/imqjmsra.jar ../lib/install/applications/__ds_jdbc_ra/__ds_jd
 bc_ra.jar ../lib/install/applications/__cp_jdbc_ra/__cp_jdbc_ra.jar .
 ./lib/install/applications/__xa_jdbc_ra/__xa_jdbc_ra.jar ../lib/insta
 ll/applications/__dm_jdbc_ra/__dm_jdbc_ra.jar ../../javadb/lib/derby.
 jar ../../javadb/lib/derbyclient.jar ../../javadb/lib/derbynet.jar ..
 /../javadb/lib/derbytools.jar ../../javadb/lib/derbyrun.jar ../lib/in
 stall/applications/jaxr-ra/jaxr-ra.jar

**sebastien.hebert** · 08/11/2010, 22h43

Salut !

Concernant le point 2, voici quelques infos.

Sous Glassfish V2 (Java EE 5), par exemple un EJB StatusServiceBean dans le package fr.sydisnet.service.impl qui déclare une interface @Remote intitulée StatusServiceRemote, cette dernière étant dans le package fr.sydisnet.service a une entrée globale JNDI accessible comme suit :

Code :

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

1
2
3
 
Context ctx = new InitialContext();
StatusServiceRemote service = (StatusServiceRemote) ctx.lookup("fr.sydisnet.service.StatusServiceRemote");

Sous Glassfish V3 (Java EE 6), ce même code est portable (pour des raisons de compatibilité car Glassfish utilise "the full-qualified interface" comme entrée JNDI). Depuis Java EE 6, la spec a introduit l'espace de nommage "java:global" pour plus de portabilité entre serveurs d'applications.

Si l'EJB StatusServiceBean est déployé dans un module EJB (toto-ejb), lui-même déployé dans un EAR (toto), le nom JNDI devient "java:global/toto/toto-ejb/StatusServiceBean".

D'où le code :

Code :

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

1
2
3
 
Context ctx = new InitialContext();
StatusServiceRemote service = (StatusServiceRemote) ctx.lookup("java:global/toto/toto-ejb/StatusServiceBean");

Tu peux également utiliser la méthode statique doLookup() de la classe InitialContext :

Code :

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

1
2
 
StatusServiceRemote service = InitialContext.doLookup("java:global/toto/toto-ejb/StatusServiceBean"); // cast non nécessaire

Par contre, ça ne fonctionne pas si ton EJB implémente deux interfaces (par exemple une locale StatusServiceLocal et une distante StatusServiceRemote) et dans ce cas, tu dois préciser l'interface dans le nom JNDI avec le nom du package dans lequel elle réside :

Code :

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

1
2
 
StatusServiceRemote service = InitialContext.doLookup("java:global/toto/toto-ejb/StatusServiceBean!fr.sydisnet.service.StatusServiceRemote");

Après, tu peux éviter les lookup JNDI avec @EJB comme le dit Alexis.

Par contre, ça ne marchera que si ton module WAR ou ACC (dans lequel tu injectes ton EJB avec @EJB ou @Inject) est déployé dans le même serveur d'applications que le module EJB.

Si ton module WAR ou ACC (Application Client Container) est déployé dans un autre serveur d'applications et que tu ne veux pas utiliser les JNDI Lookup, c'est tout-à-fait possible avec une balise <ejb-ref>. Par exemple, dans sun-web.xml, tu injectes la ressource EJB distante :

Code :

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

1
2
3
4
5
6
7
8
9
 
...
 
<ejb-ref>
    <ejb-ref-name>monEJB</ejb-ref-name>
    <jndi-name>corbaname:iiop:192.168.1.30:3700#fr.sydisnet.service.StatusServiceRemote</jndi-name>
</ejb-ref>
 
...

Tu remplaces par la bonne IP et le port (par défaut, c'est 3700 pour le port de l'ORB dans Glassfish v2 et v3) et tu suffixes par le nom de l'interface --> fr.sydisnet.service.StatusServiceRemote).

Dans le web.xml, tu mappes la référence injectée avec l'interface :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
...
 
<ejb-ref>
        <ejb-ref-name>monEJB</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
        <remote>fr.sydisnet.service.StatusServiceRemote</remote>
</ejb-ref>
 
...

Maintenant, dans ton code, tu injectes avec :

Code :

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

1
2
3
4
5
6
 
...
 
@EJB(name="monEJB")
 
...

Bonne réception.

**sebastien.hebert** · 08/11/2010, 23h15

Une petite précision concernant CDI (Context & Dependency Injection). Il faut pour cela l'activer. Pour cela, tu crées un fichier beans.xml (même vide) dans ta web app sous WEB-INF. Ensuite, tu peux injecter tes EJB en utilisant l'annotation @Inject à la place de @EJB. Par contre, il semblerait que @Inject ne permette pas d'injecter des EJB distants. Tu peux en revanche injecter des EJB locaux (avec @Local ou @LocalBean).

Enfin, utiliser un client lourd pour te connecter à un EJB distant peut se faire avec l'ACC (Application Client Container) et l'outil appclient. La contrainte est d'installer sur le poste client une distrib Glassfish pour pouvoir utiliser appclient. Tu peux afin d'éviter cela utiliser Java Web Start.

Une autre alternative consiste à créer un client jar standalone en incluant dans les dépendances de ton appli glassfish-embedded. En effet, il semblerait que glassfish-embedded intègre les classes de l'ORB Glassfish.

Du coup, dans ton code client, il suffit d'écrire :

Code :

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

1
2
3
4
5
6
 
...
 
InitialContext.doLookup("corbaname:iiop:<ton_ip_glassfish_distant>:<ton_port_glassfish_distant>#fr.sydisnet.service.StatusServiceRemote");
 
...

J'ai testé, ça marche :

**alexandre.granier** · 24/10/2011, 14h18

Bonjour,
Merci pour toutes les réponses. Doit-on en conclure qu'il n'est pas possible de se connecter à un EJB distant (tournant sur glassfish 3) avec une application utilisant les librairies javaee.jar et appser-rt.jar ? C'est à dire sans gf-client.jar.
En gros est-ce qu'on doit mettre à jour les clients si on met à jour le serveur (v2. -> v3) ?

On passe d'un dépendance envers 2 jars à une dépendance envers plus d'une centaine...

Si quelqu'un a une expérience la-dessus ?
merci.

Alexandre

[Glassfish v3] Portage JEE 5 vers 6. La meilleure construction ear et méthode d'invocation EJB possibles sont?

Glassfish et Payara Java

Discussions similaires

Partager

Partager