Oui, c'est vrai ça, tiens !!!!!
Oups, j'étais tellement dans mon truc que je ne m'en étais même pas rendu compte.
C'est pas très beau ...
Oui, c'est vrai ça, tiens !!!!!
Oups, j'étais tellement dans mon truc que je ne m'en étais même pas rendu compte.
C'est pas très beau ...
Savez-vous comment on récupère le path des ressources downloadées sur le poste client à partir de l'applet ?
J'ai essayé la solution de fxrobin en faisant :
Mais j'ai toujours null dans url ????
Code : Sélectionner tout - Visualiser dans une fenêtre à part URL url = getClass().getResource("jniApi.dll");
Pourtant ma dll est contenue dans un jar (à la racine) qui est bien indiqué dans mon fichier jnlp via la balise nativeLib ????
Alors, à mon avis il faut que tu fasses une classe "LibLoader" par exemple que tu mets dans le même JAR que tes DLL.
ensuite tu fais une méthode static dedans au même endroit (racine) qui te permettra de récupérer un inputstream dessus :
et tu l'appelles comme ça :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 class LibLoader { public static InputStream getResource(String name) { return LibLoader.class.getResourceAsStream(name); } }
pour que ça fonctionne il faut que tes dll et "LibLoader" soient dans le même package, sinon il faudra que tu donnes un chemin absolu pour le nom de ta dll.
Code : Sélectionner tout - Visualiser dans une fenêtre à part LibLoader.getResouce("madll.dll");
Si c'est à la racine, c'estClass.getRessoure résoud relativement au fullname de la classe
Code : Sélectionner tout - Visualiser dans une fenêtre à part URL url = getClass().getResource("/jniApi.dll");
Salut,
Bon ré-essai ce matin à tête reposée :
Au final, j'ai réussi à faire fonctionner le getResource ainsi :
et le System.loadLibrary ainsi:
Code : Sélectionner tout - Visualiser dans une fenêtre à part cl.getResource("jniApi.dll");
En fait, je me suis aperçu que mon jar contenant les DLLs était corrompu => j'ai refait le jar et c'est OK.
Code : Sélectionner tout - Visualiser dans une fenêtre à part System.loadLibrary("jniApi");
Conclusion: après quelques tests, je n'ai finalement pas le choix => je suis obligé de faire modifier le code de l'api par l'équipe extérieure (j'espère qu'ils vont accepter) car leur code, même en mettant les DLLs au même endroit que l'api, cela ne fonctionne pas.
(pour rappel, pour récupérer le chemin de la DLL, ils font
Merci à vous 2 pour votre aide.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7 URL codeURL = ApiJNI.getProtectionDomain().getCodeSource().getLocation(); String path = URLDecoder.decode(codeURL.getFile(), "UTF-8"); path = (new File(path)).getCanonicalFile().getParentFile().getAbsolutePath(); File libFile = new File(path, libName); String path = libFile.getAbsolutePath(); System.load(path);
Visiblement, tu as le code de la librairie externe. Moi je ne me casserais pas la nenette si ils refusent => je patch moi même, puisque de toutes façons, c'est moi qui distribue le jar
Exact,
Je supprime le .class qui m'ennuie et je le remplace par le mien, le tout repackagé dans le JAR ... et hop
Disons qu'un petit coup de jad rend bien des services quand on a aucune doc
Pour vos solutions, c'est la 1ère chose que j'ai fait. Malheureusement (ou heureusement, ça dépend du point de vue), leur jar est signé par un certificat (que je ne détiens pas bien sûr)
Auriez-vous une idée par hasard sur le problème suivant ?
Dans mon fichier JNLP principal où j'ai défini mon applet, je définis mon extension vers un autre fichier JNLP ainsi que des propriétés système.
Dans mon applet, quand je fais un Sytem.getProperty(), cela me retourne null. Si maintenant, je mets les propriétés système dans le fichier jnlp d'extension, je récupère bien mes propriétés ?????
Voici mon fichier JNLP principal portant l'applet
Et mon JNLP secondaire nativeLib.jnlp
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 <?xml version="1.0" encoding="UTF-8"?> <jnlp spec="1.0+" codebase="" href=""> <information> <title>Agent de communication</title> </information> <security> <all-permissions/> </security> <update check="always" policy="always"/> <!-- Application Resources --> <resources> <java href="http://java.sun.com/products/autodl/j2se" version="1.6+"/> <jar href="AgentComSigne.jar" main="true"/> <extension name="nativeLib" href="nativeLib.jnlp"/> <property name="log4j.configuration" value="log4j.properties" /> <property name="local" value="false" /> </resources> <applet-desc name="Agent de communication Applet" main-class="AgentCommunicationJNLP" width="400" height="30"></applet-desc> </jnlp>
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 <jnlp spec="1.0+" codebase="http://55.37.68.56/" href="nativeLib.jnlp"> <information> <title>Librairies natives</title> </information> <security> <all-permissions/> </security> <resources> <nativelib href="externaljars/nativeLib.jar"/> </resources> <component-desc/> </jnlp>
ton applet est signée ?
Oui
Une piste tout de même => mon fichier jnlp est externe à mon jar et lui n'est pas signé ... (mais c'est aussi le cas pour mes extensions donc ??? )
Piste à étudier demain ...
Y'a possibilité de mettre mes jnlp dans mon jar contenant l'applet et de les appeler depuis ma page web ?
Ah bon ? on peut faire ça
Oui bon, d'accord, un JNLP qui fait référence à un jar dans lequel il est contenu, je t'accorde ton joker. Je vais plutôt aller me coucher là, ça sera mieux pour tout le monde
Euh, finalement, mon idée n'était pas si saugrenue que cela.
En lisant les specs JSR-056 => http://fr.scribd.com/doc/6677/jnlp1-0-1spec au chapitre 5.4.1, on peut voir:
A JNLP file is signed by including a copy of it in the signed main JAR file
.
The copy must match theJNLP file used to launch the application. The signed copy must be named:
JNLP-INF/APPLICATION.JNLP
. The
APPLICATION.JNLP
filename should be generated in upper case,but should be recognized in any case
Test effectué et ça fonctionne => mes propriétés système sont maintenant bien lues
je trouve quand même discutable cette "technique" ...
Et bien ce qui est bien avec Java, c'est qu'on a beau en faire depuis des années, on en apprend tous les jours. Merci pour l'info.
Précision sur la solution => il faut valoriser les attributs codeBase et href malgré qu'il soit indiqué dans la doc oracle que le mieux est de les laisser vides ...
Sinon, on se tape un BadFieldException: Le champ <jar>href contient une valeur non valide dans le fichier de lancement signé ...
Par contre, est-il normal que quand j'indique en codeBase => http://monIP, cela ouvre une nouvelle console java lorsque j'exécute mon applet ????
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager