getResourceAsStream dans une API

Bonjour,

Je sais que le sujet est recurant mais je ne trouve pas la solution.

J'ai une API contenant dans images. Dans cette meme API j'ai une methode static permettant d'aller chercher ces images et qui contient :

Code:

---

1 2	InputStream is; is = ClassLoader.getSystemClassLoader().getResourceAsStream("com/fdilogbox/tools/resources/flag/" + codeFlag.toLowerCase() + ".png");

---

Si je lance les TU de cette API ca marche bien.

Ca se complique lorsque j'utilise cette API dans une application, la, il ne trouve plus les images :-(

Une idée? J'ai essayé pas mal de chose dont :

Code:

---

1 2 3

Flag.class.getClassLoader().getResourceAsStream(...) Flag.class.getResourceAsStream(...)

---

Mais ce ne marche pas.

Salut,

Sans connaitre la structure exacte de ton application et la localisation du fameux fichier introuvable à l'exécution, pas facile de te donner une réponse claire :aie:

Tu dis que ca ne marche pas dans ton appli.
C'est quoi ton appli : un jar, un war, un ear, etc ?

Ensuite, comment est packagé ton image dans ton appli ?
Il est dans un jar, un war, etc ?

Exacte :calim2:

Alors, mes images sont dans un jar. Le meme jar ou il y a ma methode static pour y acceder.

Mon application est elle aussi dans un jar. Mais le jar de mes images n'est pas englober dans le jar de mon application mais mis a coté (classpath dans le manifest).

J'espere qu'il y a toutes les info.

Salut,

Merci pour les précisions :ccool:
Ca m'a l'air plutôt cohérent : tu utilises un chemin relatif à partir du System. Par contre, je suis pas sûr du résultat avec le classLoader que tu utilises. Perso, je ne l'utilise jamais pour charger manuellement une ressource.

Essaye de remplacer ClassLoader.getSystemClassLoader().getResourceAsStreap() par
System.class.getClassLoader().getResourceAsStream("/com/fdilogbox/tools/resources/flag/" + codeFlag.toLowerCase() + ".png");
Note bien le / en début de chaine.

Merci.

Par contre j'ai une erreur : NullPointerException. sur le System.class.getClassLoader()

Une idée?

J'ai déjà été confronté plus ou moins au même genre de problème et parfois en bidouillant un peu, par exemple en copiant la ressource dans un fichier temporaire avant de l'exploiter, ça résous certains problème. (Mais il est évident que ça ne t'aideras pas à enlever ta NPE sur le System.class.getClassLoader)

Apres si vous voyez d'autre moyen pour aller chercher une icone dans un jar, je suis preuneur :zoubi:

System.class.getClassLoader() te renvoie un nullpointerException ????
Je pense que ca doit plutot te renvoyer null (le nullpointer c'est quand t'appelles getResource() ).

Arf, c'est surement parce que ta classe System a été chargée par le classloader bootstrap. Dans les webapps sur lequel je travaille, ce n'est pas le cas je pense.

Essaye avec le classLoader du thread en cours, ca ca marche tout le temps :aie: A moins que tu n'aies pas de thread. Mais si c'est le cas, félicitations, t'as créé une nouvelle implémentation de java :aie:
Non sans blague, j'espère que ca va marcher cette fois :D

Code:

---

1 2	Thread.currentThread().getContextClassLoader().getResourceAsStream("com/fdilogbox/tools/resources/flag/" + codeFlag.toLowerCase() + ".png");

---

Note bien l'absence de / cette fois. C'est comme si il y en avait déja un par défaut.

Et si ca marche pas, ma dernière proposition serait d'utiliser le classloader d'une classe se trouvant dans le jar qui contient ta ressource à charger (ca pourrait être la classe avec la méthode statique qui se charge justement de récupérer la ressource).
Je pense qu'en passant par le classloader qui a chargé une classe se trouvant dans le même jar, il devra être content :aie:
L'inconvénient de cette solution, c'est qu'on corrèle notre ressource à une classe. Mais bon tu veux une solution à tout prix, je m'exécute :aie:

Code:

---

1 2	TaClasseQuiFaitLeGetResource.class.getResourceAsStream("/com/fdilogbox/tools/resources/flag/" + codeFlag.toLowerCase() + ".png");

---

Note bien la présence de / cette fois :aie: sinon chemin relatif.

si les images sont dans le jar, même jar qui contient la classe dont le boulot est de les charger, alors le plus propre c'est de passer par le classloader de cette dite classe.

Tu n'a aucune garantie que le classloader sytème ou que le classloader courant n'aie accès à cette classe, il peux y avoir des tonnes de raisons pour ça (classloader custom pour un plugin, architecture J2EE, etc).

Salut tchize_,

Je comprends bien.
Maintenant, comme évoqué plus haut, je trouve que cette solution qui marche à coup sûr présente un inconvénient : on corrèle notre ressource à une classe. Aussi, je la trouve pas si propre que ca...
Imaginons que notre jar ne contient que des fichiers xml et pas de classe java, comment faire alors ? Exemple peut-être abbérant mais c'est arrivé sur un projet que j'ai récupéré récemment et comme solution de contournement j'ai dû créé une classe java dont le seul but est de charger la ressource.
Je me demandais justement cette après midi si il n'y avait pas une solution moins lourde...

D'après toi, il n'est pas possible de faire autrement (en passant par getResource() ou un autre moyen tout aussi direct)??

si le jar ne contient pas de code, le code de chargement se trouvera dans une autre jar. Donc la question que tu te dois te poser dans ce cas:

Est-ce que mon jar dois pouvoir voir ces images? Si oui, alors mettre les jar-ressources dans les références classpath: du jar contenant le code faisant le chargement, et garder le même principe.

Sinon, où suis-je supposé trouver les image? Dans "l'application courante"? Alors utiliser le classloader "courant" (accessible via Thread.getContextClassLoader).

Pour donner deux exemples:

Tu as besoin de charger une config base de donnée. Typiquement cette configuration sera fournie par l'application. Donc le contextClassLoader fera l'affaire.

Tu as besoin de charger un bout de javascript qui n'est pas supposé être modifié indépendament de ton application, alors utiliser le classloader de la classe courante.


Note que tu n'est pas lié à la classe, mais à son classloader, qui peut inclure de nombreux jar!

Merci de ta réponse.
Elle appelle une autre question :aie:

Citation:

---

Envoyé par tchize_

Est-ce que mon jar dois pouvoir voir ces images? Si oui, alors mettre les jar-ressources dans les références classpath: du jar contenant le code faisant le chargement, et garder le même principe.

---

Tu entends quoi par mettre les jar-ressources dans les références classpath: du jar ?
Ajouter dans l'attribut Class-Path du MANIFEST.MF le chemin vers le jar qui contient les fichiers ressources ou autre chose ?

oui c'est ce que je voulais dire. Imaginons un jar avec un "theme", donc juste des images des des fichiers de config. Ton application qui utilise ce "theme" (donc le code qui aura besoin de charger) aura accès à ce thème via le MANIFEST.MF donc, c'est d'office dans le même classloader que le code, donc le classeloader de la classe du code fait l'affaire.

Intéressant :)
Je vais tester ça demain.

Merci pour toutes ces reponses.
Bon j'ai trouvé mon problème : mon ant construisait mal mon Jar : il ne mettait pas les images :aie: . Du coup suivant si je compilais par netbeans ou par le ant je n'avais pas le meme resultat (d'où mon TU qui marchait mais pas mon application).