Version imprimable
Bonjour,
Est ce que l'utilisation d'EJB avec TomEE oblige l’utilisation d'OpenEjb aussi ? (En serveur Standalone)
J'ai choisi TomEE pour son coté léger et aussi parce qu'il comprenait déjà OpenEjb alors je ne vois l’intérêt de le rajouter.
Quelqu'un peut il m'aider à comprendre ?
En vous remerciant.
TomEE est une distribution incluant OpenEJB, tu n'as pas besoin de l'installer en plus, par contre, tu es obligé de passer par cette implémentation d'un conteneur d'EJBs.
TomEE contient :
- CDI - Apache OpenWebBeans
- EJB - Apache OpenEJB
- JPA - Apache OpenJPA
- JSF - Apache MyFaces
- JSP - Apache Tomcat
- JSTL - Apache Tomcat
- JTA - Apache Geronimo Transaction
- Servlet - Apache Tomcat
- Javamail - Apache Geronimo JavaMail
- Bean Validation - Apache BVal
Merci OButterlin pour ta réponse.
Que veux tu dire par "tu es obligé de passer par cette implémentation d'un conteneur d'EJBs" ?
Rien de bien important, OpenEJB est l'implémentation Apache d'un conteneur d'EJB, un serveur JBoss en a une autre, GlassFish également...
Dans tous les cas, si tu utilises TomEE, autant utiliser leur implémentation. Si elle n'est pas bonne (chose que je ne sais pas puisque je ne l'utilise pas), tu pourras toujours changer ton fusil d'épaule et passer sur un serveur JBoss (Wildfly) ou GlassFish.
Il y a une raison particulière pour utiliser ce serveur ?
Oui, je dois choisir l'architecture d'une application web Java EE qui sera grand public (un peu comme leboncoin, blablacar etc..)
Je recherche un serveur d'application léger, ne pensant pas utiliser toutes les spécifications Java EE je me suis dis que partir sur un Tomcat serait pas mal.
Mais je souhaite utiliser JPA avec EclipseLink et forcément je suis obligé d'utiliser les EJB ce qui m'a obligé à passer à TomEE (en restant sur du Tomcat)
Mais peut être que je me trompe. Je ne sais pas quel est le serveur d'application le plus adapté pour ce type d'application web. La majorité des sites étant développé avec PHP je trouve peu de références sur le web.
Actuellement j’essaie de déployer 3 projets JPA, EJB et WEB avec eclipse. (Je suis au début du développement)
Tu n'as pas besoin des EJB pour JPA, ce sont 2 choses distinctes.
Il faut voir JPA comme un "cahier de charges" pour la manipulation d'enregistrements de base de données, une sorte "d'interface".
JPA n'est pas une implémentation, Hibernate et TopLink sont des implémentations de JPA mais on peut les utiliser en dehors de JPA (enfin pour Hibernate en tout cas, ça, je connais :mrgreen:)
Si tu cherches à faire une application simple sans toutes les couches EE, un Tomcat suffit, tu rajoutes les jar (dans /WEB-INF/lib) qui vont bien pour la persistence et hop, ça fonctionnera très bien.
Oui, j'utilise EclipseLink pour implémenter JPA mais j'ai besoin d'EJB Entities / Session pour ça non ?
Je pourrais donc utiliser EclipseLink ou Hibernate sans implémenter JPA et donc sans utiliser d'EJB ?
Par quoi les EJB Entities seraient t'ils remplacé ?
As tu un avis concernant un serveur d'application adapté à mes besoins ?
J'ai toujours développer des applications de gestion pour entreprise et jamais d'application web grand public, j'avoue être dépassé par les choix technologiques et n'ayant pas de référent technique la tâche est plus compliquée.
Merci beaucoup en tout cas pour ton aide ! :D
Oui, Hibernate peut s'utiliser en dehors de JPA, ou dans le cadre de JPA mais sans EJB...
L'intérêt de JPA est de définir un contrat commun de manipulation des données indépendamment des spécificités des implémentation.
Du coup, si tu changes l'implémentation (Hibernate -> TopLink ou l'inverse par exemple), ça continuera de fonctionner sans modification du code.
En contre partie, tu perds certain éléments qui pourraient être intéressants.
Si tu n'as pas trop d'aisance avec le monde EJB, je te conseille vivement les implémentations "natives" des frameworks de persistance.
Je ne pourrais pas t'aider avec TopLink (je ne connais pas) mais avec Hibernate oui.
Le problème que tu risques de rencontrer avec les EJBs et le conteneur Web est le cloisonnement des 2 mondes avec JTA.
Dès que tu quittes le conteneur EJB, les entities sont "détachées". Les propriétés en lazy loading non initialisées à ce moment sont définitivement inaccessibles, ça risque de te surprendre si dans une page xhtml (ou jsp) tu voulais afficher une sous-propriété de ce type...
Dans le cas d'une implémentation "native", ce que je faisais était d'ouvrir la session Hibernate (la connexion à la DB) dès le début du request et je la fermais à la fin de la réponse. Comme ça, elle sera toujours libérée et tu auras toujours la possibilité de charger tardivement une propriété en lazy loading)
Y a 't-il une raison particulière pour laquelle tu souhaites utiliser EclipseLink plutôt que Hibernate ?Citation:
Envoyé par Tom1x
- Qu'est ce que tu veux dire par implémentations "natives" des frameworks de persistance ?
Techniquement concernant le cloisonnement avec JTA lorsque par exemple je fais quelque chose comme ca dans ma servlet :
List<Objet> objets = objetService.findAll();
Objet est référencé d'une entitie du projet JPA et findAll() est une fonction de mon EJB qui à pour but de récupérer tous les objets en base.
- Je ne pourrait plus récupérer mes données à un moment donné dans ma servlet ou jsp ?
- J'ai entendu dire que c'était une bonne pratique de mapper des entities avec des DTO (par exemple avec Dozer) qu'en pensez vous ?
Pour ceux que ca intéresse j'ai réussi à faire fonctionner un projet EJB et un projet Web avec TomEE il suffisait d'exporter le projet EJB en jar dans le dossier WEB-INF/lib du projet web.
@ddoumeche : Je n'ai eu aucune aide ou conseils d'un expert ou référent technique alors j'ai fais avec les info du web pour faire mon choix technologique, c'est risqué mais il faut bien choisir.
Mon choix s'est porté sur EclipseLink parce que j'ai lu ici => http://www.jpab.org/EclipseLink/Post...QL/server.html qu'il était plus performant qu'hibernate avec Postgresql le SGBDR que j'utilise et peut être moins complexe aussi mais évidemment ne l'ayant pas testé je ne peux pas en être sur.
- D'ailleurs avez vous des conseils à me donner concernant un choix de framework web qui collerait avec mon besoin ?
Je souhaite rester sur quelque chose de léger avec une bonne doc et pas trop complexe.
Le plus simple serait d'aller sur le site Hibernate, tu aurais un tour complet...Citation:
Envoyé par Tom1x
En résumé :
- le HQL est un langage de requête lié à Hibernate (le mode natif)
- le JPQL est un langage de requête lié à JPA (dont Hibernate pourrait être l'implémentation, mais TopLink également)
Les 2 langages ont des points communs mais aussi pas mal de différences.
Si tu comparais l'objet Criteria de JPQL et l'objet Criteria de HQL, tu constaterais que c'est le jour et la nuit... la version Hibernate étant LARGEMENT plus intuitive ;)
Bref, le but de JPA est d'avoir une façon de faire unifiée pour plusieurs implémentations, le but de Hibernate est de faire un maximum de chose, à leur manière et donc non transposable à un autre framework de persistance (ORM) comme TopLink, EclipseLink, etc...
Dans ta servlet, si ton objet "Objet" contient des sous-objets mappés en FetchType.LAZY et que tu ne les as pas chargé, tu auras une erreur à l'exécution.Citation:
Envoyé par Tom1x
La raison est que ton entity n'est plus attaché à son contexte de persistance, on ne peut donc plus effectuer les sous-requêtes nécessaires pour charger les données... bref... c'est mort :aie:
Pour ce qui est des DTO, je fais partie des défenseurs de cette technique qui a de nombreux avantages, en voici 3 intéressantes :
- transfert uniquement les données utiles à la couche de présentation
- abstraction des données entre la couche de présentation et le modèle physique des données
- plus de problème de lazy loading
Tu trouveras sur le net de nombreuses discussions sur le thème avec souvent l'argument "ça ne sert à rien si on a les mêmes propriétés dans les entities et les dto" sauf que : même si on a le reflet des entities dans les DTOs, l'entity n'est pas forcément chargée, pire, si le mapping change au fil du temps, une ancienne application pourrait ne plus fonctionner (on passe de FetchType.EAGER à FetchType.LAZY).
Je te demande cela car Hibernate est l'implémentation de référence, et que la documentation est de meilleure qualité selon moi.Citation:
Envoyé par Tom1x
Qu'EclipseLink soit légèrement plus rapide qu'Hibernate sur Postgresql, oui c'est possible. Mais avec les bugs en moins aussi.
Ceci dit, maintenant que ton projet est démarré, tu ne vas pas changer