Pourquoi nous devons déclarer les dépendances sur le manifeste de JBOSS 8 (wildfly)?

le suivant à l'OREILLE:

my-app.l'oreille
- mon ejb.jar
- mon-webapp.la guerre
- lib
  - mon-lib.jar

mon ejb besoin de l'oracle de la bibliothèque pour travailler avec oracle spatial pour la construction de la géométrie et de stocker des données. Le module de la suite oracle est correctement chargé par JBOSS 8 (wildfly).

Quand j'ai commencé à l'application, j'ai reçu ClassNotFoundException oracle.sql.STRUCT.

OK, j'ai ajouté la dépendance de pilote oracle ojdbc6.jar sur mon ejb META-INF/manifest.mf.

Class-Path: ojdbc6.jar
Dependencies: oracle.sql

Quand j'ai commencé à l'application, j'ai reçu ClassNotFoundException oracle.sql.StructDescriptor. Je sais que quand je lis des données vers et à partir d'un jeu de résultats, l'objet de sortir du jeu de résultats est une instance d'une oracle.sql.STRUCT classe, mais la oracle.sql.StructDescriptor est dans le même package.

OK, j'ai ajouté la même dépendance de pilote oracle ojdbc6.jar sur mon-lib META-INF/manifest.mf.

Et ça marche!!!

Ma question est

qui est le rôle de manifets sur JBOSS 8?
pourquoi sur oracle weblogic je n'ai PAS besoin d'ajouter ces dépendances sur le manifeste.mf?

OriginalL'auteur giusy | 2014-08-14

7

Pour répondre à votre question:
- qui est le rôle de manifets sur JBOSS 8?
Manifestes sont créés automatiquement chaque fois qu'un pot d'archive est créé. Il n'y a pas de rôle spécifique liée à JBOSS 8 mais son objectif général. Dans le cas particulier d'un pot de dire file1.jar dépend de certaines classes appartenant à un autre bocal dire file2.jar fichier, puis ceux des bocaux doivent être chargés au moment de la file1.jar est en cours de chargement. Maintenant, le truc est, chaque fois qu'un fichier jar est chargée par un chargeur de classe, qui se manifeste est une façon de dire classloader pour charger d'autres pots qui ce pot besoins. (Suivez ce lien) C'est la raison pour laquelle vous code ne fonctionne pas lorsque ojdbc6.jar est manquant dans le manifeste.
- pourquoi sur oracle weblogic je n'ai PAS besoin d'ajouter ces dépendances sur le manifeste.mf?
Bien, c'est parce que dans oracle weblogic, le ojdbc6.jar est livré avec weblogic server et est déjà chargé au démarrage du serveur. Veuillez noter que même si vous avez livré ojdbc6.jar dans votre application, il n'est pas utilisé. Voici la la documentation pertinente pour cela.

OriginalL'auteur Santosh
14

Santosh a donné la bonne réponse, mais permettez-moi de clarifier certaines questions sur weblogic vs jboss.

JBOSS et WebLogic ont différentes classoader mécanisme. Permettez-moi de préciser:

1. pourquoi manifester?

Java-Oracle répondre: Vous devrez peut-être référence de classes dans d'autres fichiers JAR dans un fichier JAR.

2. pourquoi manifeste sur l'OREILLE/GUERRE d'application?

Oracle Weblogic répondre: WebLogic Server prend en charge les paquets optionnels comme décrit dans la Java EE 5.0 de la Spécification, la Section 8.2 Forfait Optionnel de Soutien, avec gestion des versions décrites dans le Package Optionnel de contrôle de version. En option paquets fournissent des fonctionnalités similaires à Java EE bibliothèques, vous permettant de facilement partager un seul fichier JAR entre plusieurs applications. Comme avec Java EE les bibliothèques, les paquets optionnels doit d'abord être enregistré avec WebLogic Server en déployer les associés fichier JAR un forfait optionnel. Après l'enregistrement de l'emballage, vous pouvez déployer des applications Java EE des modules de référence de la trousse dans leur manifeste de fichiers.

Paquets optionnels diffèrent de Java EE bibliothèques parce que les paquets optionnels peuvent être référencées à partir de n'importe quel module Java EE (de l'OREILLE, JAR, WAR, ou l'archive RAR) ou explosé répertoire des archives. Java EE les bibliothèques peuvent être mentionnés seulement à partir d'un valide Application d'Entreprise.

[...]

Toute application Java EE ou d'un module peut faire référence à un package optionnel (à l'aide de META-INF/MANIFEST.MF), alors que seules les Applications d'Entreprise, applications Web et peut faire référence à une partagées Java EE de la bibliothèque (à l'aide de weblogic-application.xml ou weblogic.xml)

3. alors, pourquoi nous ont pas de déclarer java-ee-api.jar, jsf, jsp, ...

Jboss répondre: Le tableau suivant répertorie les modules sont automatiquement ajoutés à des déploiements que les dépendances et les conditions de déclenchement de la dépendance.

Implicit_Module_Dependencies

4. ne sont pas tous les modules chargés par JBOSS?

Jboss répondre: ce chapitre traite de la façon dont les applications sont emballés comme les pots peuvent déclarer qu'ils dépendent l'un ou plusieurs modules:
```
Dependencies: oracle.sql, another.module.with.version:1.0
```
Manifeste des informations de module

4.1 alternativement définir la jboss-deployment-structure.xml
```
<jboss-deployment-structure>

   <deployment>

      <dependencies>
         <module name="oracle.sql" export="TRUE" />
      </dependencies>

   </deployment>

</jboss-deployment-structure>
```
Ajouter anExplicit Module de Dépendance à un Déploiement

4.2 avec maven
```
<plugins>

   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-war-plugin</artifactId>
      <configuration>
         <archive>
            <manifestEntries>
               <Dependencies>org.javassist, org.apache.velocity</Dependencies>
            </manifestEntries>
         </archive>
      </configuration>
   </plugin> 

</plugins>
```
voir: Générer MANIFESTMF entrées à l'aide de Maven

voir: Comment pouvez-vous générer les dépendances des modules dans le MANIFESTE.MF pour JBoss as 7 avec maven?

7. pourquoi nous n'avons pas cette information importante avant?

Avec le nouveau modèle d'organisation de JBOSS 7/8 abandonne la célèbre classloading hiérarchie pour passer à un modèle simple basé sur l'utilisation d'unités modulaires (JBoss Modules De Projet) . L'introduction de l'architecture des modules (en plus de l'introduction prochaine dans le JDK, fort en vogue à cette époque grâce à des projets externes tels que OSGi) s'étend en fait le modèle à utiliser pour l'emballage des applications Java EE; un module peut alors être une bibliothèque, une collection de classes, ou plus généralement d'une collection de ressources associées à un seul chargeur de classe: par conséquent, à la différence du passé, où le chargeur de classe qui ont été recueillies dans une organisation hiérarchique d'un ensemble de classes, le point de vue est exactement inversée.

voir: Chargement de classe dans WildFly

OriginalL'auteur venergiac

Vous devez vous connecter pour publier un commentaire.