Accéder aux EJB par une Applet,servlet et jsp

**hterrolle** · 16/02/2007, 19h49

Bonjour,

Je cherche a me renseigner sur les differrente possibilité de communication qu'il est possible d'avoir avec un EJB.

Il semblerait que la communication entre apllet,servlet,jsp et un EJB soit possible.

J'ai cherché sur le net de examples des ces possibles communication, ainsi que les informations deternimant les cas ou cette communication est impossible. Je n'est pas vraiment trouvé de reponse clair.

Je m'adresse donc a vous en esperant que quelqu'un pourra m'aider a trouver une reponse a mes questions concernant les possibilité de communication avec un EJB.

Merci d'avance.

***alexandre*** · 16/02/2007, 20h44

Un EJB pour être accessible doit être instancié correctement rien de bien magique la dessus

les divers tutoriaux disponibles sont assez explicifs

**hterrolle** · 16/02/2007, 22h44

bonjour *alexandre*,

D'apres se que j'ai compris la simple notion d'instznciation n'est pas sufisante puisqu'il le container web doit entrer en relation avec le container Ejb.

C'est là ou j'ai un peut de difficulté.

Pourrait tu s'il te plait me donner l'adresse d'un tutorial comprenant un example de cette communication entre container.

merci

***alexandre*** · 17/02/2007, 05h54

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
    private NewEntityFacadeLocal lookupNewEntityFacade() {
        try {
            Context c = new InitialContext();
            return (NewEntityFacadeLocal) c.lookup("java:comp/env/ejb/NewEntityFacade");
        }
        catch(NamingException ne) {
            Logger.getLogger(getClass().getName()).log(Level.SEVERE,"exception caught" ,ne);
            throw new RuntimeException(ne);
        }
    }

NewEntityFacadeLocal est ton SessionBean
Sinon pour un tutorial :

http://psecheresse.developpez.com/tu...va-ee/partie1/

**hterrolle** · 26/02/2007, 10h24

re bonjour,

voila se que j'ai trouvé sur le sujet. La communiation avec les EJB peuvent se faire de deux manières.

1) Standalone application client (java code (applet,frame,GUI)) (externe au serveur)
2) application client starting from the serveur

Dans les premier cas il n'est pas possible d'utiliser les annotations @EJB (ou bien je ne pas compris comment le faire)

dans le deuxième cas il faut utiliser les annotations @EJB (sinon cela ne fonctionne pas)

ceux qui veux dire qu'il faut donc depoyer sur le serveur son application client et modifier celui ci si ont veux l'axecuter en standalone depuis la machine client.

Merci de me corriger si il y a quelque chose que je n'est pas compris.

***alexandre*** · 26/02/2007, 10h36

Dans le cas ou ton code est managé tu peux utilisé la déclaration @EJB dans le cas de code non managé il faut faire un appel explicite JNDI

managé

Code :

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

1
2
 
Note that you can use dependency injection only in managed classes such as servlets, ejbs, etc. and not in regular Java classes and you have to use JNDI to look up an instance of entity manager as follows:

CF https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
http://www.theserverside.com/tt/arti...=MigratingJDBC

**hterrolle** · 26/02/2007, 10h55

salut,

donc il faut bien develloper un code pour un client standalone(loockup) et un client accessible a partir du serveur (@EJB) ?

***alexandre*** · 26/02/2007, 16h41

Du côté client tu fais un lookup sur ton session bean (remote)

EDIT si tu veux accéder un session bean alors la il te faudra communiquer avec une servlet qui elle utilise @EJB

EDIT 2 pas certain que ca soit nécessaire de passer par une servlet
http://www.oracle.com/technology/sam...sion_bean.html

**hterrolle** · 26/02/2007, 19h23

Salut alexandre,

En fait pn peut tres bien utiliser @EJB avec un standalone et une application client (localise sur le serveur).

En fait c'est Netbeans qui plantait lorsque j'essayais de lancer l'application client a partir de l'IDE.

Donc je rectifie:

les annotations @EJB sont valable aussi bien pour les standalone que pour les aplication localise sur le serveur.

Cela ressemble a une injection comme en Spring.

Entre nous, se coup si il ont assuré chez sun.

***alexandre*** · 26/02/2007, 19h27

Ca m'étonne même beaucoup. Et ca me fait remettre en question plusieurs choses.

Par contre quand tu dis

En fait pn peut tres bien utiliser @EJB avec un standalone et une application client (localise sur le serveur).

c'est bien un appel en remote que tu dois faire ?

**hterrolle** · 26/02/2007, 20h09

Salut,

Je vais te donner le detail des test qui m'on ammener a ce constat.

j'ai utilisé netbean comme IDE sur mon portable.

J'ai donc developer mon code dans l'IDE est ensuite deployer sur le serveur.

Donc en appellant mon application par le browser ou en utilisant appclient(cmd windows). Il faut dire que le xxx-xxx-esrClient.jar était localiser dans une directorie appartenant au seerveur.

Mais dans les deux cas j'ai pu utiliser @EJB pour faire appel au class concernées.

L'injection fonctionne bien. Elle est juste codé en dur dans le fichier java se qui donne de l'avenir au utilissatuer de Spring.

***alexandre*** · 26/02/2007, 20h13

Merci de ces précisions, personellement j'ai pas encore compris je ne puisse pas utiliser l'injection dans une entité Page du framework click http://click.sourceforge.net/

mise à par que ce ne soit pas une classe managé ... pourquoi une classe normale le serait ayant un attribut context ...

***alexandre*** · 26/02/2007, 20h22

Envoyé par hterrolle

Salut,

Je vais te donner le detail des test qui m'on ammener a ce constat.

j'ai utilisé netbean comme IDE sur mon portable.

J'ai donc developer mon code dans l'IDE est ensuite deployer sur le serveur.

Donc en appellant mon application par le browser ou en utilisant appclient(cmd windows). Il faut dire que le xxx-xxx-esrClient.jar était localiser dans une directorie appartenant au seerveur.

Mais dans les deux cas j'ai pu utiliser @EJB pour faire appel au class concernées.

L'injection fonctionne bien. Elle est juste codé en dur dans le fichier java se qui donne de l'avenir au utilissatuer de Spring.

Pour spring ... justement il n y a plus d intérêt à l utilisé étant donné que l'injection est faite par les annotions

CQFD

L intérêt d'EJB 3.0 (et des annotations) est de supprimer les fichiers de config ... tel qu'application context ... Par contre pour Quartz ou Acegi es-ce que c'est les framework qui devront être redéfinis ? ou les prochaines versions seront accessibles par annotations !

Vive l'POA

Et quartz pour le schedulling est super simple d'uage ... pareil pour acegi

**hterrolle** · 26/02/2007, 20h50

ca fait plaisir,

Merci pour le lien je le garde.

C'est clair que EJB3 a de beau jour devant lui. Mais la faexiblité de spring n'est pas remise en question. Même si spring ne permet pas tout. Il faut voir le code pour en parler.

M'enfin EJB3 fonctionne pas mal. Le seul proleme maintenant c'est comment commnoquer a l'interieur d'un serveur ?

***alexandre*** · 26/02/2007, 21h16

La communication est faite uniquement par les annotations. Tu peux être même plus explicite que par un fichier de conf.

L'IoC c'est pas compliquer, tu définis pour un bean particulier une référence sur un autre bean.

Code :

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

1
2
3
4
5
6
7
 
<bean name="bidule">
 <ref bean = "autre">
</bean>
 
<bean name="autre">
...

La programmation par aspect, (annotations) c'est pas compliqué tu définis avant un appel de méthode ce que tu définis dans un fichier de configuration

un bean bidule définit donc en attribut
@Invocation (class="autre")

et par la reflection des annotations tu invokes la bonne classe et la bonne méthode

Pour un server c'est facile, tu définis le contexe d'une invocation avant l'appel d'une méthode

tu rajoute donc un attribut (annotation bis) qui est définit ou non lors du runtime

donc pour une certaine méthode tu peux définir

@Invocation (condition="remote") ou condition peut être dynamique, remote, local (déterminé lors de l'appel)

**®om** · 26/02/2007, 22h09

Envoyé par *alexandre*

Dans le cas ou ton code est managé tu peux utilisé la déclaration @EJB dans le cas de code non managé il faut faire un appel explicite JNDI

managé

Code :

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

1
2
 
Note that you can use dependency injection only in managed classes such as servlets, ejbs, etc. and not in regular Java classes and you have to use JNDI to look up an instance of entity manager as follows:

CF https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html
http://www.theserverside.com/tt/arti...=MigratingJDBC

Comment ça se fait que dans mes Servlets, si je mets @EJB devant MonEJBFacade, sa valeur soit toujours null, il n'est pas initialisé...?

***alexandre*** · 26/02/2007, 22h13

Lors de la déclaration dans ta servlet tu définis bien

@EJB Mafacade

ta facade local est bien définit en

@Stateless

public class MaFacace

@PersistenceContext
private EntityManager em;

***alexandre*** · 26/02/2007, 22h15

Envoyé par ®om

Comment ça se fait que dans mes Servlets, si je mets @EJB devant MonEJBFacade, sa valeur soit toujours null, il n'est pas initialisé...?

C'est pas possible que ca soit nul, si tu utilises correctement l'annotation @EJB

**hterrolle** · 27/02/2007, 08h23

Salut,

J'ai eu le même probleme en utilisant netbeans pour executer mon application client.

En effet si tu essaie de faire un "run project" depuis ton project application ckient. L'injection ne fonctionne qu'avec un loockup.

Par contre si tu execute ton application en standalone ou depuuis le browser l'injection fonctionne dans les deux cas.

Accéder aux EJB par une Applet,servlet et jsp

Java EE

Discussions similaires

Partager

Partager