Resource fichier non trouvée

Bonjour,
Je m'arrache les cheveux avec ça depuis des heures.
Mon programme n'arrive pas à trouver une ressource fichier, quand je le lance à partir de sa version jar. Quand je lance à partir de mon IDE il le trouve.
Le fichier est là, j'ai vérifié, je le copie au build dans le même répertoire que mes jar, dont je teste le déploiement:
zweegercore.jar
zweeger.jar
zweegerexe.jar
preferences.properties

je démarre zweegerexe.jar et je cherche "/preferences.properties" en faisant
un

Code:

---

1 2	URL url=this.getClass().getResource(pathToFile); return new File(url.toURI());

---

où le getResource me retourne null quand je lance l'application dans le contexte jar8O8O

A savoir (si ça a un intérêt): la classe "this" avec laquelle je fais le getResource, se trouve dans zweegercore.jar....

Merci pour votre aide

Bonjour,

Tu lances ta commandes à partir d'où ?

Le fait de faire getResource sur une classe récupère un fichier dans le contexte de la classe.

Dans ton cas, il cherche le fichier "preferences.properties" dans le jar. Comme tu as précisé "/preferences.properties", il doit chercher le fichier à la racine de ton Jar.

Merci pour vos réponses.

Citation:

---

Envoyé par flo.87

Le fait de faire getResource sur une classe récupère un fichier dans le contexte de la classe.

---

C'est vrai que ça marche bien avec un autre fichier .properties qui est dans le jar. Ca expliquerait bien des choses, mais alors cette FAQ serait-elle incorrecte ? Sauf si le getResource et le getResourceAsStream se comportent différemment.

Citation:

---

Envoyé par Anthony.Desvernois

Tu lances ta commandes à partir d'où ?

---

Via un command-prompt avec le prompt dans le répertoire de mes jar.

Bon j'ai procédé autrement. Plutôt que passer via des getResource je passe directement via un getFile:

Code:

---

return new File(System.getProperty("user.dir")+File.separator+pathToFile);

---

En conclusion:
- ça me coupe toute possibilité d'inclure ces fichiers dans le jar,
- ça ne me dit pas pourquoi ça ne marchait pas avec get getResource,
- mais ça fonctionne, c'est ce qui m'importe aujourd'hui.

Merci pour vos remarques.

Si le fichier que tu ouvres est destiné à être modifié, tu n'aurais pas pu (sauf erreur de ma part), le placer dans un Jar.
En effet, il n'est pas possible d'ajouter, de modifier ou de supprimer un fichier présent dans un Jar (sauf reconstruire tout le Jar).

Pour en revenir à ton problème initial,

Si tu veux ajouter un dossier au classpath de ton Jar, tu édites le MANIFEST.MF (sorte de fichier de configuration de Jar) pour ajouter la ligne :

Code:

---

Class-Path: dossier/

---

Et dans ce cas-là, tu peux accéder aux fichiers présents dans le dossier par la ligne :

Code:

---

this.getClass().getResource("/fichier");

---

Merci. Je vais essayer ça. J'avais pas du tout pensé à cette option.

Ma solution du

Citation:

---

Code:

---

return new File(System.getProperty("user.dir")+File.separator+pathToFile);

---

---

ne marche pas dans tous les cas :evilred:
Je développe un plugin audio, à intégrer dans un hôte audio, l'hôte étant un choix de l'utilisateur.

Dans 80% de mes tests, le System.getProperty("user.dir") retourne le répertoire où se trouve le jar de mon plugin. Mais dans 20% des cas, il retourne un autre emplacement. En fait il retourne le chemin de démarrage d'un Command Prompt sous windows (Menu Démarrer--> Run-->"cmd").

D'où la question: par quel moyen atteindre à 100% ces ressources fichiers qui sont dans l'arborescence de mon jar de démarrage ?

Salut,

Citation:

---

Envoyé par lvr

C'est vrai que ça marche bien avec un autre fichier .properties qui est dans le jar. Ca expliquerait bien des choses, mais alors cette FAQ serait-elle incorrecte ? Sauf si le getResource et le getResourceAsStream se comportent différemment.

---

Pourquoi serait-elle incorrect ?

getResource() permet d'accéder à une ressource du classpath, mais il faut bien prendre en compte que ce n'est pas forcément un fichier au sens du système d'exploitation !

Citation:

---

Envoyé par lvr

Dans 80% de mes tests, le System.getProperty("user.dir") retourne le répertoire où se trouve le jar de mon plugin. Mais dans 20% des cas, il retourne un autre emplacement. En fait il retourne le chemin de démarrage d'un Command Prompt sous windows (Menu Démarrer--> Run-->"cmd").

---

Ce qui est tout à fait normal : "user.dir" représente le répertoire de travail, qui dépend fortement de la manière dont on lance l'application...

Citation:

---

Envoyé par lvr

D'où la question: par quel moyen atteindre à 100% ces ressources fichiers qui sont dans l'arborescence de mon jar de démarrage ?

---

Dans l'exemple que tu donnes, le fichier n'est pas dans ton jar mais à coté...


Donc il faudrait savoir :

• Où veux-tu que ton fichier soit placé ?
• Doit-il être accéder en lecture ou en écriture ?

a++

Merci de ta réponse rapide. Mon soft malgré qu'il soit en version beta, faiblement annoncé est déjà référencé sur plusieurs sites, avec ses bugs, ça craint :aie::aie::aie::aie:

Les réponses:
Ma structure de fichier est la suivante, dans un répertoire au choix que je connais pas, car choisi par l'utilisateur à l'unzip.

.\zweeger.dll :

le plug, qui est un wrapper VST(norme C de plugins audio) -> java. Ce plug crée un nouvel objet d'une classe référencée dans le fichier de config

.\zweeger.ini:

le fichier de config du wrapper, où je lui indique quelle est la classe à instancier et où la trouver ainsi que les jar du wrapper

.\zweeger\zweeger.jar

Le jar de mon application qui contient les classes et des ressources non modifiables (dtd + application.properties)

.\zweeger\preferences.properties

Les préférences de l'utilisateur. Le unzip en amène une version par défaut. Modifiable par l'utilisateur

.\zweeger\default.zwg

Un "fichier"/"objet"/"document" chargeable dans l'application: c'est comme le Normal.dot dans Word: ça sert à l'initialisation et c'est modifiable.

.\zweeger\Icons\lfo.png

Les icônes de l'application. Rem: Auraient pu être dans le jar, mais comme j'avais tout écrit en parcourant tout le contenu du répertoire \Icons\ et en le chargeant, et que ceci n'est pas possible dans un jar, je les ai laissées en dehors du jar.

Rem: je n'ai aucun contrôle sur zweeger.dll (c'est le wrapper) et, je ne modifie zweeger.ini que dans le sens décrit pas son auteur (classpath, classe du plugin, options du wrapper, ...)

Citation:

---

Dans l'exemple que tu donnes, le fichier n'est pas dans ton jar mais à coté...

---

Je me suis mal exprimé.
En résumé, mes ressources statiques (sauf les icônes) sont dans le jar.
Les ressources dynamiques sont à côté du jar. Ce sont celles-là que j'ai du mal à atteindre de manière systématique (ex: default.zwg)

quand t'as absolument besoin de connaitre l'endroit où se trouve ton application, pour y lire des fichiers de configuration par exemple, le plus simple est de recourir à un installeur qui créera un fichier .bat ressemblant à ceci:

Code:

---

1 2	java '-DMonDossier=c:\Installation\de\machin' -jar machin.jar

---

car si il n'y a pas de moyen fiable de détecter où se trouve ton application (et pour cause elle pourrait meme ne pas etre locale), un installeur, lui, connait l'endroit où on lui a demandé d'installé, et il peut préparer le .bat approprié.

au fait, en java, ce qui n'est pas dans le classpath (comme tes fichier .ini en dehors du jar), n'est pas une "resource"

En effet la manière dont tu vas déployer l'application va avoir une incidence ! Le principal problème des fichiers à l'intérieur d'un jar, c'est qu'ils ne sont pas modifiable...

Quelques solutions :

• Si tu utilises Java Web Start une solution serait de passer par PersistenceService.
• Sinon une solution serait d'avoir les fichiers en double : un dans le jar avec les valeurs par défaut, et un dans le répertoire de l'utilisateur (new File(System.getProperty("user.home"), ".monappli")) qui sera donc modifiable par l'utilisateur.
• Enfin si ton application est en local, tu peux utiliser les ressources pour retrouver le nom du fichier jar, et donc son emplacement sur le disque (voir ce message : http://www.developpez.net/forums/d67...x/#post3949248 )

a++

Tchize, adiGuba, Merci.
Le problème d'essayer de mémoriser une info à l'installation, c'est que si chaque utilisateur de mon plugin, travail de la même manière que je bosse avec les plugins des autres (les déplacer, les réorganiser, les supprimer, ... : j'ai plus ou moins 200 plugs installés 8O), aucune info figée à l'installation n'est viable.

Donc la troisième solution d'abiGuba me semble parfaite. J'ai presque envie de brosser le boulot pour aller l'essayer chez moi ;) Je vous tiens au courant.

Résolu. Merci. Cette 3ème solution a fait l'affaire.