Bonjour,
Je viens vers vous parce que j'ai un soucis de "splitting" de projet
Actuellement, j'ai un projet monolithique contenant des EJB et des Entities. Mon but serait de le splitter de façon à avoir un projet contenant mes EJB, et un autre contenant mes Entities.
Travaillant sur Eclipse, j'ai donc un projet EAR contenant un autre projet EJB Module. J'ai donc récupéré les Entities de ce projet EJB Module pour créer un Utility Module.
C'est là que s'imposent les soucis.
Premièrement, j'ai essayé d'inclure cet Utility Module (le projet) comme dépendance du projet EJB Module, déjà pour la construction (à travers le Java Build Path), puis pour le déploiement à travers le Deployment Assembly. L'inconvénient et ce qui est incompréhensible, c'est que l'entrée dans ce dernier défini un chemin de déploiement à la racine du jar... Un jar dans un jar ? Alors que pour des User libraries tels que log4j, il veut bien me les déployer dans le répertoire lib/ de l'EAR.
Donc, je me dis qu'il vaut mieux le déployer à l'échelle de l'EAR. Je vire donc ce que j'ai fais vis-à-vis des dépendances et je rajoute donc dans le Deployement Assembly de mon projet EAR l'Utility Module. Là, c'est nickel. Il veut bien me le déployer dans lib/NomDuJar.jar.
Pour la construction, l'EJB Module ayant pour dépendance EAR Libraries, tout est ok.
Cependant, lorsque je déploi mon EAR sur JOnAS 5.2.4, BOOM. Il me dit qu'il ne trouve pas une classe qui est censée être présente dans l'Utility Module. Je vérifie donc la ligne Class-Path du MANIFEST.MF de l'EJB Module et il n'est pas recensé, contrairement à Log4J. Ce qui est logique puisque je l'ai "déclaré" à l'échelle de l'EAR. Je l'ai quand même rajouté manuellement et rien n'y fait, il veut pas me le charger.
Sachant que cette classe est utilisée dans un MDB, je suspecte quelque chose à ce niveau là.
Faut-il obligatoirement avoir les MDB et les classes qu'ils utilisent dans le même .jar ? Auriez-vous des idées, s'il vous plait ?
Partager