Problème de déploiement de Java EE

Question

Je rencontre des problèmes lors du déploiement de mon application Java EE et je pourrais avoir besoin de conseils.
j'ai 3 composants pour déployer:

• couche d'intégration (Data): POJOs et haricots CDI - fichier JAR
• de couche d'application (BL): EJB, grains de CDI et POJOs - fichier JAR
• Présentation couche: servlets et tel - fichier WAR

Idéalement, je voudrais être en mesure de déployer les fichiers JAR d'intégration et de la couche d'application dans le même serveur Java EE, mais comme JARs séparés (depuis que je pourrais vouloir changer la configuration matérielle plus tard et séparez-les en deux serveurs différents sur deux machines séparées).
Le problème est que je n'arrive pas à faire fonctionner l'injection CDI du JAR de la couche d'intégration au JAR de la couche d'application. Le serveur dit (et probablement à juste titre) qu'il est impossible de résoudre les injections.

Jusqu'à présent, je suis venu avec ces solutions possibles:

• Package deux JARs en un seul fichier EAR (peut-être jeter dans la guerre et ...), et déployer que
• JNDI
• Dans la couche d'intégration, placez les objets injectés dans les EJB de la couche d'application (DAO) au lieu des haricots CDI.

Je n'aime pas l'une ou l'autre de ces solutions (surtout la dernière), car elles limitent mes futures options de déploiement. La deuxième solution ne me limite pas, mais elle peut devenir fastidieuse à un moment donné (quand j'accumule beaucoup de code).

Enfin, ma question est la suivante:
Y at-il une option que je ne trouve pas encore, qui me permettrait de déployer les deux fichiers JAR sur le même serveur avec les injections de travail CDI? Peut-être quelque chose qui fonctionnerait encore si à un moment donné je sépare les JARs en différents serveurs?

Answer 1

Oui, il existe également d'autres options.

1. Utilisez un conteneur Java EE qui prend également en charge OSGi et utilisez l'interface OSGi pour vos dépendances de déploiement. Au moins Websphere, Glassfish, JBoss (avec jbosgi installé), Jonas supporte le déploiement de bundles OSGi. Cela signifie que vos modules doivent être convertis en bundles OSGi.

2. Utilisez une extension spécifique au conteneur qui permet aux modules de communiquer entre eux. JBoss comme jboss-deployment-structure.xml que vous pouvez utiliser pour avoir une dépendance à un autre déploiement.

3. Utilisez un chemin de classe partagé fourni par le serveur pour vos dépendances. Je ne le recommanderais pas vraiment.

Mon vote irait pour OSGi.

Aucun d'entre eux ne fonctionnera par lui-même si vous déployez des packages sur des serveurs différents. Une technologie distante comme les EJB distants, les recherches JNDI distantes, l'accès distant Spring, l'API HTTP, CORBA ou similaire est nécessaire entre différents serveurs. En Java EE, EJB est la norme de facto pour cela, mais Spring remoting n'est pas mauvais non plus.

---

Mise à jour: vous avez ajouté que vous utilisez des serveurs TomEE. En effet, TomEE ne supportera pas les deux premières options que j'ai mentionnées. J'utiliserais EJB dans ce cas - le fait que vous utilisez des EJB peut être extrait de la couche de gestion en utilisant un délégué EJB, et vous pouvez utiliser EJB (bean session sans état) uniquement pour la partie interface, laissant vos DAO comme POJOs .

Answer 2

ne sais pas ce que votre objectif est, mais le déploiement d'une guerre est très bien, peut même être fait manuellement à l'aide de ces commandes:

mkdir -p webapps/myapp/WEB-INF/lib 
cp myjar*.jar webapps/myapp/WEB-INF/lib/ 

Si votre objectif est d'être en mesure de les séparer, vous pouvez utiliser la fonction de guerre maigre tomee .

Créez une guerre avec un fichier WEB-INF/jars.txt.

Dans ce jars.txt mettre une ligne par dépendance/jar. Cela peut être le chemin vers les coordonnées du pot ou de la maven. Une fois installé, il vous permettra de changer les bocaux un par un puis de simplement redémarrer le serveur. C'est génial quand plusieurs équipes travaillent sur le même binaire.

Il existe une alternative avec TomEE mais celle-ci a l'avantage d'être facile à changer en portable (guerre).