Bonjour tout le Monde Oreille: NoModuleFileException: Un fichier n'existe pas pour le module élément ayant uri: core-api.jar
J'ai ce qu'est un simple fichier EAR configurée comme suit:
app.ear
|-- lib/...
|-- META-INF/application.xml
|-- core.jar
| |-- test/MyServiceImpl.class
| `-- META-INF/MANIFEST.MF //Class-Path: core-api.jar
|-- core-api.jar
| `-- test/MyService.class
`-- web.war
`-- META-INF/MANIFEST.MF //Class-Path: core.jar core-api.jar
L'application.xml est comme suit:
<?xml version="1.0"?>
<application xmlns="http://java.sun.com/xml/ns/javaee" id="app 1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd" version="6">
<application-name>MyApp</application-name>
<display-name>My App</display-name>
<module id="mod 1">
<java>core-api.jar</java>
</module>
<module id="mod 2">
<java>core.jar</java>
</module>
<module id="mod 3">
<web>
<web-uri>web.war</web-uri>
<context-root>/</context-root>
</web>
</module>
<library-directory>lib</library-directory>
</application>
Lorsque je tente de déployer l'application sur le serveur, j'obtiens l'exception suivante:
[*] 00000088 SystemErr R Caused by: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.NoModuleFileException: A file does not exist for module element having uri: core-api.jar
[*] 00000088 SystemErr R at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.checkType(ModuleRefImpl.java:591)
[*] 00000088 SystemErr R at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.initModuleFileFromEAR(ModuleRefImpl.java:167)
[*] 00000088 SystemErr R at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.getModuleFile(ModuleRefImpl.java:120)
[*] 00000088 SystemErr R at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EARFileImpl.getModuleFile(EARFileImpl.java:165)
[*] 00000088 SystemErr R at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EARFileImpl.getDeploymentDescriptor(EARFileImpl.java:817)
[*] 00000088 SystemErr R at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.getDeploymentDescriptor(ModuleRefImpl.java:230)
[*] 00000088 SystemErr R ... 49 more
Je suis à l'aide de Websphere Environnement de Test v8.5.5.0
mise à JOUR: je m'en doutais peut-être que l'algorithme de compression utilisé pour compresser le fichier ear peut être à blâmer, et il semble comme si j'étais de droite; la décompression et rezipping l'oreille fichier à l'aide de 7zip a provoqué le déploiement de travailler sans erreurs.
Je suis à l'aide de gradle comme un outil de construction qui fournit un mécanisme de compression des archives. J'ai essayé le réglage de la entryCompression
mode de ZipEntryCompression.STORED
sans succès.
Ceci m'amène à une nouvelle question:
-
Comment puis-je contrôler le montage/la compression du fichier ear pour se conformer à ce que Websphere attend?
et
-
Quelle méthode ne gradle utiliser pour compresser l'oreille?
mise à JOUR 2: à la Recherche à la gradle code source, je peux voir le Zip de la mise en œuvre utilise la fourmi org.apache.tools.zip.ZipOutputStream
(1.9.3). quelqu'un a eu de la difficulté avec ce processus avant?
Mise à JOUR 3: Il me semble que si j'ai été à la poursuite d'un hareng rouge. J'ai inspecté le fichier qui est censé être déployé correctement et vu que l'oreille contenait un dossier extra niveau au-dessus de la racine de l'oreille (c'est-à app.ear!app/<root>
).
en supposant que les algorithmes de compression ont rien à faire avec elle, quelqu'un a une idée?
Mise à JOUR 4: Ok, je suis vraiment très proche, j'ai réussi à obtenir le déploiement de travail après l'inspection de quelques exemples de fichiers ear et de tester différentes théories. j'ai fait ces choses, et il a travaillé (voir mise à Jour 5).
- Au lieu de java modules dans le application.xml j'ai modules ejb
- J'ai inclus une base META-INF/ejb-jar.xml fichier dans le core.jar (même si la spec dit que vous n'en avez pas besoin) que websphere apparemment ne l'aime pas quand il manque
- J'ai enlevé le core-api.jar module à partir de la application.xml
Donc, j'ai maintenant la suivante application.xml:
<?xml version="1.0"?>
<application ...>
<application-name>MyApp</application-name>
<display-name>My App</display-name>
<module id="mod 1">
<ejb>core.jar</ejb>
</module>
<module id="mod 2">
<web>
<web-uri>web.war</web-uri>
<context-root>/</context-root>
</web>
</module>
<library-directory>lib</library-directory>
</application>
Une dernière question: comment puis-je déployer " un artefact à l'oreille projet sans l'ajouter à l'application xml? sinon, comment puis-je personnaliser l'application.xml après les déploiements ont été résolus?
Mise à JOUR 5: Excuses pour la fluctuation de l'état de ma question.
Bien que l'application déployée avec succès, il ne démarre pas, ce qui me donne un message d'erreur indiquant que mon ejb jarres avait pas d'ejb. Depuis, j'ai décidé, en suivant les conseils que j'ai reçu et aussi une réponse ci-dessous, que mon de printemps à base de pots sont classées comme "utilitaire" pots et doit vivre dans le dossier lib.
Je m'attends à utiliser ces pots dans des Ejb dans l'avenir et tiens à les garder dans le dossier lib, plutôt que directement dans la guerre.
c'est mon dernier application.xml:
<?xml version="1.0"?>
<application ...>
<application-name>MyApp</application-name>
<display-name>My App</display-name>
<module>
<web>
<web-uri>web.war</web-uri>
<context-root>/</context-root>
</web>
</module>
<library-directory>lib</library-directory>
</application>
Je vous remercie pour votre temps et de la patience.
La libs dir était une faute de frappe, c'est-à-dire
lib
j'ai fixé. comme pour les classes/interfaces pots, y aurait-il un but pour l'avoir dans le répertoire de racine? Je remarque que eclipse place automatiquement ejbClient pots dans la racine, donc j'ai suivi son exemple.Je n'ai pas eu votre question pouvez-vous donner des précisions sur cette "
as for the classes/interfaces jars, would there be a purpose for having it in the root directory? I notice that eclipse automatically places ejbClient jars in the root as well so i followed suit.
"
OriginalL'auteur coderatchet | 2014-07-29
Vous devez vous connecter pour publier un commentaire.
Eh bien, je peux voir votre application.xml l'en-tête que vous êtes en utilisant JavaEE 6 de l'emballage et vous avez également mentionné que vous êtes à l'aide de WebSphere 8.5.5 donc suivre quelques oreille des informations sur l'emballage.
Vous n'avez pas besoin de l'application.xml si vous utilisez annoté EJB 3.x et puis suivre l'emballage standard de convention:
Remarquez que c'est le défaut d'emballage de Java EE 6 structures et à la suite de tout cela l'utilitaire de pots que vous placez dans le répertoire lib seront disponibles à la fois pour les Ejb et les Guerres que vous avez là de sorte que vous devriez utiliser ce répertoire seulement si votre utilitaire de pots sont nécessaires à la fois par les Ejb et web applications. Si votre utilitaire jar est uniquement utilisé par votre application web que vous devez emballer à l'intérieur de la norme de WEB-INF/lib du dossier en vous guerre seulement.
Maintenant, si vous êtes en utilisant les Ejb 2.x avec votre emballage que vous aurez besoin d'avoir la application.xml et de déclarer votre ejb et de la guerre, vous devriez garder à l'approche recommandée de laisser les utilitaires pots à l'intérieur du dossier lib et ceux requis uniquement pour le web la couche à l'intérieur du dossier lib de la guerre paquet.
Si pour une raison quelconque vous voulez garder votre utilitaires pots au niveau de la racine ou de l'oreille, vous pouvez utiliser l'approche de déclarer au Manifeste pour l'OREILLE, mais que vous N'avez PAS et ne peut pas déclarer de nouveau dans le manifeste pour la guerre paquet. Déclarer tous les pots sur l'oreille manifeste sera automatiquement visible par le chargeur de classe de la guerre de fichiers et les Ejb.
La javaEE 6 specifiction Chapitre 8 "Demande d'Assemblage et de Déploiement" a l'explication complète sur ce sujet. Vous pouvez télécharger le document ici.
OriginalL'auteur groo