Lors de l'exécution de JAR, obtenez ExceptionInInitializerError: version.properties non trouvée

Question

J'ai écrit un petit projet dans Eclipse qui fonctionne parfaitement dans l'EDI. Ensuite, j'ai construit un fichier .jar exécutable via Eclipse (qui devrait inclure toutes les bibliothèques de dépendances dans le fichier jar lui-même).

J'utilise 3 bibliothèque dans mon projet:

• derby.jar
• qtjambi-4.7.1.jar
• qtjambi-win32-msvc2008-4.7.1.jar

Ensuite, j'utilise cette commande (dans Windows):

java -jar prova.jar 

Et Je reçois ceci:

Connected to database 

Exception in thread "main" java.lang.reflect.InvocationTargetException 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
    at java.lang.reflect.Method.invoke(Unknown Source) 
    at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa 
der.java:58) 
Caused by: java.lang.ExceptionInInitializerError: version.properties not found! 
    at com.trolltech.qt.Utilities.<clinit>(Unknown Source) 
    at com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(Unknown Source) 
    at com.trolltech.qt.QtJambiObject.<clinit>(Unknown Source) 
    at WAAAGH.main(WAAAGH.java:52) 
    ... 5 more 

Comme vous pouvez le voir le derby.jar fonctionne comme prévu (« Connecté à la base de données »), mais il y a une erreur avec Qt Jambi-que je ne comprends pas. Une idée?

EDIT: WAAAGH est la classe qui contient la méthode principale, la ligne 52 consiste à:

QApplication.initialize(args); 

Answer 1

FWIW l'emplacement de version.properties a été récemment modifié pour être à l'intérieur de l'espace de nom de package des bundles com/trolltech/qt/version.properties. L'ancien emplacement était un mauvais choix de conception et cela a maintenant été corrigé. Le problème est que si vous avez un autre JAR dans votre classpath qui a aussi un fichier toplevel alors le ClassLoader est autorisé à penser que le JAR avec ce fichier est autoritaire pour le paquet et qu'il n'a pas besoin de chercher un autre JAR pour le fichier. Un paquet est une unité déployable minimale en Java, seuls les ClassLoaders spécialisés (tels que ceux utilisés dans OSGi) ont des fonctionnalités pour contourner cette partie de la conception Java.

Habituellement votre toplevel (application JAR) sera le premier dans la liste et je parie que dans ce JAR vous avez un ou plusieurs fichiers comme /log4j.properties /commons-logging.properties etc ... c'est parce qu'un ou plusieurs le fichier existe alors masque (cache) le fichier dans le qtjambi-XYZjar d'être vu lors de l'exécution. C'est pourquoi le problème peut ne pas exister lorsque vous testez un certain scénario mais que vous apparaissez lorsque vous en essayez un autre (lorsque vous avez modifié ClassPath d'une manière ou d'une autre).

Mon engagement au projet au http://qt.gitorious.org/qt-jambi/qtjambi-community/commit/f18ce5da3e30b43424bf94e49adf8c4cac0d9862 explique mieux dans le code le changement très récent pour rendre la vie meilleure.

Il ne devrait jamais avoir été nécessaire de copier le fichier version.properties des fichiers JAR redistribuables QtJambi dans une autre partie du chemin de classe (comme dans le cas du projet prova.jar). Cela a été corrigé pour la prochaine version. C'est l'intention à long terme de supprimer complètement le besoin du fichier et je suis à 80% avec cet objectif, dans le cadre de ce travail faire coexister plusieurs JAR natifs dans le même chemin de classe simplifiera grandement le déploiement et la mise en route des guides; ainsi que les faire jouer avec OSGi et Eclipse joliment out-the-box.

Cependant, aucun changement n'a encore été fait pour inclure cette modification, mais je suis très proche (dans les 30 jours suivant cette opération pour Qt 4.7.4).

Alerte de prise en charge Open Source: veuillez envisager de vous joindre à la liste de diffusion au http://lists.qt.nokia.com/pipermail/qt-jambi-interest/ de http://lists.qt.nokia.com/mailman/listinfo pour les annonces.

Answer 2

Comment est QtJambiObject obtenir chargé? L'avez-vous conforté dans votre prova.jar? Le fichier manquant version.properties doit faire partie du même fichier au niveau supérieur (pas dans un sous-répertoire). Il semble que vous ne l'ayez pas emballé à l'intérieur prova.jar au niveau supérieur. Voir this pour l'explication de la façon dont il est chargé.

Vous pourriez être mieux spécifier tous les pots et la classe principale sur la ligne de commande:

java -classpath prova.jar;derby.jar;qtjambi-4.7.1.jar;qtjambi-win32-msvc2008-4.7.1.jar <your main class> 

remplacer; avec: si vous exécutez sur * nix