[JEE] Passer d'interfaces distantes à locales
Passer d'interfaces distantes à locales [JEE] - Java - Programmation
Marsh Posté le 05-07-2012 à 14:53:59
Bon j'ai mis à jour mon appli mais ça ne marche pas
Pour résumé : avant j'avais mon war avec mes servlets, un jar contenant les interfaces distantes, et un autre war contenant les ejb.
Là j'ai supprimé le jar des interfaces et j'ai directement mis les interfaces dans le jar des ejb.
Voilà le code
EJB :
Code :
Sélectionner tout - Visualiser dans une fenêtre à part
Code :
|
Interface :
Code :
Sélectionner tout - Visualiser dans une fenêtre à part
Code :
|
classe appelante, j'ai essayé plusieurs choses (sachant que c'est une classe du jar ejb et non du war) :
Code :
Sélectionner tout - Visualiser dans une fenêtre à part
Code :
|
Ca ça ne marche pas et ça me sort des NameNotFound :
Code :
Code :
|
Vu que je suis directement dans le jar ejb j'ai donc essayé d'injecter l'EJB dans la classe :
Code :
Code :
|
Mais là ça me sort un NullPointeur à .getConstante() ....
Donc comment m'y prendre ? Est ce qu'il faut déclarer les ejb dans l'annueaire JNDI pour les lookup ? Quel non entrer ?
Merci !
Marsh Posté le 05-07-2012 à 16:09:24
C'est le bordel dans ton truc 
Déjà :
Code :
|
Si c'est pour mapper sur un nom identique à ton EJB, tu peux virer le contenu de ton annotation.
Ensuite ta classe Constantes. Pour l'appel via context.lookup, c'est ton mapping qui est a priori faux. A voir sur la console de monitoring de ton serveur d'application, tu as possibilité de voir les mapping JNDI des ressources déployées.
Y'a quand même de grandes chances pour que ça ne soit pas "AdminBean" mais "nom-de-ton-ear/AdminBean/local". Remplace nom-de-ton-ear par son mapping si tu l'as précisé dans le descripteur de déploiement.
Enfin, pour l'injection EJB, le type est l'interface, pas l'EJB dans ton cas :
Code :
|
(même si je vois pas trop l'intérêt de le rendre dispo en statique)
Message édité par LeRiton le 05-07-2012 à 16:09:55
Marsh Posté le 05-07-2012 à 16:21:40
Super merci pour la réponse !!! 
Effectivement pour le Stateless c'était des restes des essais d'avant et je n'ai pas enlever depuis 
Pour l'interface en static, en effet ça sert à rien de l'utiliser en statique (je viens de lire sur le net) mais les méthodes de la classe Constante sont static alors obligé 
Et je viens de voir que depuis un Pojo pour injecter un EJB il faut plutôt @Inject en utilisant Java Contexts and Dependency Injection et non un @EJB.
Bref je vais déjà voir pour le JNDI et je tiens au courant ! merci en tout cas
PS:première fois que je fais du JEE donc désolé si effectivement ça peut paraitre être le bordel
Message édité par VinceSSJ le 05-07-2012 à 16:23:12
Marsh Posté le 05-07-2012 à 16:25:32
Faut déjà savoir si tu fais de l'EJB 3, les méthodes sont différentes entre les versions (EJB2.1 != EJB3).
Marsh Posté le 05-07-2012 à 16:39:28
EJB 3 
Mais d'ailleurs comment savoir concrètement quelle version est dispo ?
Parce que je sais que ce sont des EJB 3 car c'est la personne qui a développée l'appli qui me l'a dit. Mais sans ça comment je pourrais savoir ? En regardant la version du JDK utilisée ?
Marsh Posté le 06-07-2012 à 13:38:31
Tu peux compiler de l'EJB 2.1 avec un JDK 1.6.
Ton script de build (Ant, Maven) contient peut-être l'info. Le plus simple reste encore de demander autour de toi si tu bosses sur une base de code existante. Ou de regarder ledit code et spotter les différences : http://help.eclipse.org/indigo/ind [...] ejb21.html
Si c'est de l'EJB 3, te prend pas la tête avec les nommages JNDI, sa devrait pas être nécessaire dans 90 % des cas si tu utilises l'injection. Ta classes Constantes, elle a une bonne raison pour avoir des méthodes statiques alors qu'elle est dans ton conteneur EJB ? Ça serait pas un candidat à EJB Stateless ?
Marsh Posté le 06-07-2012 à 15:11:34
Okay c'est noté
Pour les différences c'est ultra visible en fait, déjà y'avait déjà les annotations (@Stateless, @Remote etc..), et pas de descripteur de déploiement pour les EJB, donc c'est signé EJB 3 obligé je suppose.
Je précise que je travaille sous Netbeans et GlassFish 3.1.
Après pour les EJB, le dev utilisait JNDI pour faire des lookup pour rechercher les EJB distant, mais travaillant en local je peux me passer de tout JNDI ?
La classe Constante, elle était placée dans le JAR des interfaces, elle contient toutes les constantes statiques nécessaire à l'appli. Et elle contient aussi des méthodes statiques qui "construisent" les constantes pour les modules de l'appli au début de l'application.. Static puisque si ces données sont modifiées l'appli ne fonctionnera plus
Par exemple une méthode :
Code :
|
Donc pour l'instant j'essaie juste d'accéder aux EJB avec cette classe que j'ai replacée dans le JAR des EJB (donc les servlets pour l'instant j'y ai pas touché)
Marsh Posté le 06-07-2012 à 15:21:05
| VinceSSJ a écrit : Après pour les EJB, le dev utilisait JNDI pour faire des lookup pour rechercher les EJB distant, mais travaillant en local je peux me passer de tout JNDI ? |
C'est bien de savoir comment ça marche, mais c'est géré pour toi.
| VinceSSJ a écrit : La classe Constante, elle était placée dans le JAR des interfaces, elle contient toutes les constantes statiques nécessaire à l'appli. Et elle contient aussi des méthodes statiques qui "construisent" les constantes pour les modules de l'appli au début de l'application.. Static puisque si ces données sont modifiées l'appli ne fonctionnera plus |
Fichier de properties + EJB Stateless qui tape dedans.
Marsh Posté le 06-07-2012 à 15:46:13
Est ce que tu pourrais détailler un peu SVP ? Je ne comprends pas tout.
"C'est bien de savoir comment ça marche, mais c'est géré pour toi. "
je n'en comprends pas le sens cherché.
"Fichier de properties + EJB Stateless qui tape dedans. "
Que veux tu dire par là ? que la classe constante se comporte comme un fichier properties ? Oui on va dire que c'est ça
EDIT :
En fait j'avais pas vu mais au lancement de l'appli dans le log tous les noms JNDI s'affichent
Code :
|
Donc j'ai mis mes lookup adaptés :
Code :
|
Sauf que là j'ai une autre erreur.. GlassFish ne peut pas créer le bean...
Code :
|
Mais quand je regarde à la fin je m'aperçois que ça vient des autres lookup que je n'ai pas encore fait donc je persévère
Message édité par VinceSSJ le 06-07-2012 à 16:28:54
Sujets relatifs:
- [Résolu] Passer une variable dans un include
- PhP: Comment passer d'une BDD SQL à SQLite?
- resoudre et passer au langage c
- bouton arrêt - finir de lire un clip avant de passer à un autre
- [BATCH] Passer une commande en argument à l'appel de cmd.exe
- passer un argument d'un JFrame à un autre
- Quel est l'équivalent de Html2PDF en JEE ?
- Etudiante ayant besoin d'aide JEE !!!!!!
- Passer div id sur une event onclick a du PHP
- USB : faire passer le PC pour un "périphérique"
Marsh Posté le 03-07-2012 à 14:51:14
Bonjour,
Après m'être documenté comme je pouvais là dessus, je cherche à repasser les EJB @Remote d'une appli JEE en EJB @Local.
L'application suit la structure Javascript<=>Servlets<=>EJB, et tout est déployé dans le même EAR, donc le passage en local est donc tout à fait possible et conseillé pour un soucis d'optimisation.
Le projet est constitué de 3 JAR : 1 pour les Sverlets/Javascript, un autre pour les interfaces des EJB, et un autre pour les EJB.
Pour rechercher les EJB une recherche de contexte est effectuée pour retrouver les classes.
Le problème est que concrètement je ne sais pas quoi changer à part les annotations.
Voici l'exemple d'un EJB :
Code :
Comme je le disais les interfaces sont tous situés dans un JAR
Code :
Dans ce JAR sont également placés tous les objets transmis entre les Servlets et les EJB, objets tous implements Serializable bien sûr
Je sais qu'il faut modifier toutes les annotations @Remote en @Local, et qu'il faut sans doute supprimer tous les implements Serializable des objets, mais que faire d'autres ? Est ce qu'il faut continuer d'utiliser l'annuaire JNDI ?
Est ce aussi simple que ça ?
Merci d'avance !
Message édité par VinceSSJ le 03-07-2012 à 14:54:21