Discussion :

[-N4w4k-]

Bonjour,

Pour commencer, je suis débutant en Java. Désolé si je ne suis pas très clair, je suis moi-même un peu perdu..

J'ai hérité d'un projet utilisant des EJB à partir duquel j'ai créé un EJB Module dans eclipse, puis, exporté en tant que EJB JAR File pour l'inclure dans une application web. Le but étant d'exécuter des méthodes du jar depuis l'application web.

La méthode que j'ai en face de moi est située dans une façade, utilisant elle-même d'autres façades. J'imagine que l'attribut @EJB indique au framework Hibernate qu'il faut instancier ces façades car je ne vois à aucun moment de maFacade = new MaFacade().

Est-ce qu'il y a moyen de faire fonctionner ces façades "normalement", même depuis une application web "standard"?

Merci d'avance pour vos lumières!

[-N4w4k-]

Je me rend compte en relisant le post qu'il manque un peu de code.. Dans l'espoir que quelqu'un ici sache m'orienter, je vais essayé de vous expliquer un peu mieux ce qui marche et ce qui ne marche pas.

J'ai inclus ma librairie d'EJB dans l'application web.
J'ai rajouté une persistence-unit dans le fichier persistence.xml de l'application web (une persistence-unit existait déjà, ça en fait 2 maintenant):

Code XML :

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
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
    version="1.0">
 
<!-- persistence-unit existante -->
    <persistence-unit name="concept" transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <properties>
            <property name="jndiName" value="java:comp/env/jdbc/concept"/>
            <property name="hibernate.cache.provider_class" value="org.hibernate.cache.NoCacheProvider" />
            <property name="hibernate.dialect" value="org.hibernate.dialect.SQLServerDialect" />
            <!-- <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle9Dialect" /> -->
            <property name="hibernate.show_sql" value="false" />
        </properties>
    </persistence-unit>
 
<!-- nouvelle persistence-unit -->
    <persistence-unit name="CoresCalculatorUnit"
        transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <non-jta-data-source>java:comp/env/jdbc/CoresCalculatorDS</non-jta-data-source>
        <jar-file>cores-calculator-1.0.jar</jar-file>
        <!-- Liste des classes de la librairie -->
        <properties>
            <property name="hibernate.connection.datasource" value="java:comp/env/jdbc/CoresCalculatorDS" />
            <property name="hibernate.dialect" value="org.hibernate.dialect.SQLServerDialect" />
            <property name="javax.persistence.jdbc.driver"
                value="com.microsoft.sqlserver.jdbc.SQLServerDriver" />
        </properties>
    </persistence-unit>
</persistence>

Dans une classe de mon application web, je réussi a instancier un EntityManager pour ma nouvelle persistence-unit, à l'utiliser pour récupérer des enregistrements:

Code java :

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

1
2
3
4
                    EntityManagerFactory emf = Persistence.createEntityManagerFactory("CoresCalculatorUnit");
                    EntityManager em = emf.createEntityManager();
                    tender = em.find(Tender.class, idsMapping.get("DC_QUOTATION_NUMBER"));
                    LOGGER.info("Tender ID: " + tender.getDcQuotationNumber());

Donc j'imagine que mon persistence.xml n'est pas si moche!

Le problème est que dans cette même classe de l'appli web, j'ai tenté de rajouter un champ:

Code :

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

1
2
    @EJB(beanName = "PrimaryCalculusBean", beanInterface = PrimaryCalculusFacade.class, description = "PrimaryCalculus Bean")
    private PrimaryCalculusFacade myPrimaryCalculusFacade;

... en espérant qu'il soit instancié lors de l'instantiation de ma classe (comme dans un projet EJB normal, non?) mais ça ne fonctionne pas, NullPointerException lors de son appel..

Il me manque des connaissances sur le sujet, et je tourne en rond à force de pas savoir quoi chercher..

[Logan Mauzaize]

Les EJB sont des objets dont le cycle de vie sont gérés par le serveur d'application (EJB container). Ils en existent plusieurs types (session, message).
Hibernate est une implémentation JPA. Cette dernière est un service fourni par les serveurs d'applications et qui gère la persistance via une base de données relationnelles. Les objets manipulés sont normalement appelés Entity. Ces objets sont gérés par JPA mais les ressources liées (connexion et transaction) sont gérées par le serveur d'application.

Tu peux soit gérer les EJB dans un "super" Tomcat (ex : TomEE) ou bien remplacer la couche JEE par Spring Framework ou autre.

[-N4w4k-]

Les EJB sont des objets dont le cycle de vie sont gérés par le serveur d'application (EJB container). Ils en existent plusieurs types (session, message).
Hibernate est une implémentation JPA. Cette dernière est un service fourni par les serveurs d'applications et qui gère la persistance via une base de données relationnelles. Les objets manipulés sont normalement appelés Entity. Ces objets sont gérés par JPA mais les ressources liées (connexion et transaction) sont gérées par le serveur d'application.

De ce que je comprend, c'est la raison pour laquelle je peux utiliser l'EntityManager mais que les EJB ne sont pas injectés.

Tu peux soit gérer les EJB dans un "super" Tomcat (ex : TomEE) ou bien remplacer la couche JEE par Spring Framework ou autre.

Erm! Tout ça m'a l'air lourd de conséquence.. Je n'ai pas le pouvoir de choisir le framework (une société tierce avec qui je n'ai pas de contact développe depuis des années un framework qu'ils vendent à mon client - je suis là seulement pour faire des changements "mineurs").

Est-ce que passer de Tomcat à TomEE nécéssite de revoir une partie du code déjà produit? (je ne sais pas si tu sais répondre sans voir le code..)

Merci pour ton aide!

Edit:

Je viens de faire une petite recherche et j'ai une partie de la réponse.

"Tomcat vs TomEE":



De ce que je vois sur ce tableau, tout ce que fait Tomcat, TomEE le fait aussi. Est ce que cela signifie que je peux mettre TomEE sans m'inquiéter pour la comptabilité du code déjà écrit?

[Logan Mauzaize]

De ce que je comprend, c'est la raison pour laquelle je peux utiliser l'EntityManager mais que les EJB ne sont pas injectés.

Si tu n'as pas de "service" pour injecter les EJB, effectivement ca ne peut pas fonctionner. EntityManager fait partie de l'API JPA dont Hibernate est une implémentation. Mais tu n'es pas obligé de tirer l'API JPA quand tu utilises Hibernate.

Erm! Tout ça m'a l'air lourd de conséquence.. Je n'ai pas le pouvoir de choisir le framework (une société tierce avec qui je n'ai pas de contact développe depuis des années un framework qu'ils vendent à mon client - je suis là seulement pour faire des changements "mineurs").

En fait, d'où vient le code avec les EJB ? Parce que j'ai l'impression qu'il sort d'un chapeau magique ... Soit c'est du code existant, et cela ne peut pas fonctionner sur un "simple" Tomcat (et donc que tu n'utilises pas la bonne cible de déploiement pour tes développements), soit c'est du neuf et un contournement serait plus judicieux.

Est-ce que passer de Tomcat à TomEE nécéssite de revoir une partie du code déjà produit? (je ne sais pas si tu sais répondre sans voir le code..)

Oui, TomEE (et ses "+") viennent avec des APIs et des implémentations spécifiques. A titre d'exemple, tu pourras constater que TomEE PluME vient avec EclipseLink et Mojarra qui sont respectivement des implémentations de JPA et JSF. Pour le second ce n'est pas très important si tu n'as pas déjà JSF ou que tu utilises déjà cette implémentation.
Pour le premier c'est plus compliqué puisque tu utilises déjà Hibernate. Et d'expérience, on a souvent des parties spécifiques puisqu'on ne peut pas toujours s'en remettre à l'API JPA "standard" pour résoudre tous les problèmes.

D'ailleurs le tableau est assez étrange puisque plusieurs APIs sont déjà mentionnés pour les autres produits mais sans spécifier les implémentations ... Mais tout ceci est détaillé sur la page de garde de TomEE :

TomEE

The Web Profile version of TomEE contains

• 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

TomEE+

The TomEE Plus distribution adds the following:

• JAX-RS - Apache CXF
• JAX-WS - Apache CXF
• JMS - Apache ActiveMQ
• Connector - Apache Geronimo Connector

Par ailleurs toutes ces librairies tirent également (par dépendances) des implémentations différentes d'APIs fournies par Java SE (ex: JAXP, JAXB). Ce qui n'est pas sans causer quelques soucis de compatibilité entre les différentes librairies qui les utilisent.

[-N4w4k-]

En fait, d'où vient le code avec les EJB ? Parce que j'ai l'impression qu'il sort d'un chapeau magique ... Soit c'est du code existant, et cela ne peut pas fonctionner sur un "simple" Tomcat (et donc que tu n'utilises pas la bonne cible de déploiement pour tes développements), soit c'est du neuf et un contournement serait plus judicieux.

C'est à la base une appli web développée par une autre équipe, comportant des fonctionnalités que l'on veut intégrer dans notre appli.
Après avoir identifié le code métier qui m'intéresse, j'ai construit ma librairie.
Quand tu parles de contournement, tu veux dire réécrire une partie de la couche d'accès aux données? Ne plus utiliser les EJB? Si oui, j'ai bien peur que ce ne soit pas possible dans le temps qui m'est donné vu la quantité de code qu'il y a, et sa compléxité. Sinon, je ne vois pas de quel type de contournement tu me parle.

Est-ce que passer de Tomcat à TomEE nécéssite de revoir une partie du code déjà produit?

Oui, TomEE (et ses "+") viennent avec des APIs et des implémentations spécifiques. A titre d'exemple, tu pourras constater que TomEE PluME vient avec EclipseLink et Mojarra qui sont respectivement des implémentations de JPA et JSF. Pour le second ce n'est pas très important si tu n'as pas déjà JSF ou que tu utilises déjà cette implémentation.
Pour le premier c'est plus compliqué puisque tu utilises déjà Hibernate. Et d'expérience, on a souvent des parties spécifiques puisqu'on ne peut pas toujours s'en remettre à l'API JPA "standard" pour résoudre tous les problèmes.

Pour JSF, je ne pense pas qu'on l'utilise (je ne trouve aucun .jsf dans l'appli).

Pour JPA, d'après Apache, TomEE and Hibernate:

A single webapp may have many persistence.xml files and each may use whichever JPA provider it needs. [...] The default JPA provider can be changed at the server level to favor Hibernate over OpenJPA.

Si je comprend bien, je pourrais donc garder Hibernate pour l'appli web et ma librairie d'EJB?

[Logan Mauzaize]

[QUOTE=-N4w4k-;8460715]C'est à la base une appli web développée par une autre équipe, comportant des fonctionnalités que l'on veut intégrer dans notre appli.[QUOTE]
L'intégration de fonctionnalités ne passent pas nécessairement par l'inclusion de code. Je t'invite à considérer des éléments comme les micro-services et la SOA de manière plus général.

Après avoir identifié le code métier qui m'intéresse, j'ai construit ma librairie.

Soit tu fais du copier/coller de code et ce n'est pas idéal et modifier le code ne devrait pas poser trop de problèmes. Soit c'est une réelle mise en commun du code et dans ce cas, il faut impérativement définir la liste des pré-requis et qui satisfassent tout le monde. Par exemple dans ton cas la dépendance aux EJB est TRÈS impactante.

D'ailleurs, je ne connais pas le code mais les EJBs sont surement "overkill".

Quand tu parles de contournement, tu veux dire réécrire une partie de la couche d'accès aux données? Ne plus utiliser les EJB? Si oui, j'ai bien peur que ce ne soit pas possible dans le temps qui m'est donné vu la quantité de code qu'il y a, et sa compléxité. Sinon, je ne vois pas de quel type de contournement tu me parle.

La couche de persitence n'est surement pas à toucher. En revanche, je pense qu'il vaut mieux 1) soit se débarrasser de la dépendance aux EJBs, 2) soit introduire une indirection. En gros tu introduis une interface qui décrit ton service et tu disposes d'une implémentation reposant sur les EJBs et une autre plus simple. Ou alors une implémentation classique sans dépendance complexe et une sur-couche qui repose sur les EJBs.

Pour JSF, je ne pense pas qu'on l'utilise (je ne trouve aucun .jsf dans l'appli).

En jetant un oeil à tes dépendances et tu le verras vite.

Pour JPA, d'après Apache, TomEE and Hibernate:
Si je comprend bien, je pourrais donc garder Hibernate pour l'appli web et ma librairie d'EJB?

Si chaque contexte de persistance peut spécifier un provider, tu pourras garder Hibernate. Pour la partie EJB, vu que tu n'en utilises pas ca ne devrait pas poser spécifiquement de problème mais je ne sais pas sur quels autres APIs il reposent (ex: CDI, JTA) mais que elle tu utiliserais.

Je ne suis pas un spécialiste de JEE et travaille générale loin de ses normes/APIs. Je préfère me focaliser sur la meilleure façon de résoudre un problème en exploitant au maximum les capacités des librairies que j'ai à ma disposition.

Ceci étant tu fais énormément mention au temps restreint mais je vois pas comment envisager une migration technique sans un minimum de temps pour la préparer, la réaliser, la tester, la valider et la déployer. D'ailleurs, tous les environnements dans lesquels j'ai travaillé ne permettent pas de choisir les méthodes et plateformes de déploiement.
Déployer, configurer, superviser, etc. un conteneur Web (Tomcat) et un conteneur EJB (TomEE, Geronimo, etc.) sont deux choses très différentes !

[-N4w4k-]

Je t'invite à considérer des éléments comme les micro-services et la SOA de manière plus général.

La solution d'un service dédié à ces nouvelles fonctionnalités est séduisante. Concrètement, cela veut-il dire qu'il faut que Tomcat tourne pour mon appli web + TomEE (ou autre serveur d'application prenant en charge les EJB) pour le projet EJB? Puis que les 2 applications communiquent entre-elles à travers un web service?

Ceci étant tu fais énormément mention au temps restreint mais je vois pas comment envisager une migration technique sans un minimum de temps pour la préparer, la réaliser, la tester, la valider et la déployer

Le truc c'est que beaucoup de chose ont été à prendre en compte pendant l'analyse (base de données, UI, code métier, etc), et que je n'imaginais pas que Tomcat puisse être un soucis à un moment ou un autre. En ce moment je suis dans la réalisation, et une dead-line est déjà fixée..

[Logan Mauzaize]

La solution d'un service dédié à ces nouvelles fonctionnalités est séduisante. Concrètement, cela veut-il dire qu'il faut que Tomcat tourne pour mon appli web + TomEE (ou autre serveur d'application prenant en charge les EJB) pour le projet EJB? Puis que les 2 applications communiquent entre-elles à travers un web service?

Je préfère dire simplement "service" La tuyauterie pourra être tout et n'importe quoi qui corresponde à tes contraintes techniques (déploiement, latence, débit, etc.) : middleware, OSGi, pattern "Service", SOAP, REST, XML RPC, CORBA, RMI, etc.

[-N4w4k-]

Ok je vois. Beaucoup de choses inconnues pour moi, mais les possibilités sont là. C'est la solution qui me parait la plus judicieuse, je vais regarder tout ça plus en profondeur maintenant.

Merci pour ton aide, tes interventions ont été très pertinentes et m'ont beaucoup fait avancer!

[Logan Mauzaize]

En relisant la discussion, je me rends compte que j'ai oublié de te donner un lien que je voulais mentionner : https://docs.oracle.com/javaee/7/tutorial/

Ce n'est pas parfait car pour certaines parties, il ne fait que du survol mais déjà ca présente toutes les notions et APIs de JEE (version 7), ce qui peut te permettre d'y voir plus clair et ensuite d'aller chercher des infos plus détaillées sur ce qui t'intéresse plus particulièrement.

En tout cas bon courage !