Discussion :

[fxrobin]

De mémoire, je n'avais pas mis les DLL dans un JAR, mais directement dans le répertoire.

Ensuite, déclarée dans le lanceur JNLP et s'était tout.
et le .jar de l'API JNI Wrapper de la DLL, biensûr.


et en mode "debug" qu'as tu dans la variable "location" et dans ta variable "codeURL" ?

[maverick5051]

Comment as-tu déclaré tes DLLs dans ton lanceur ?
Parce que c'est ce que j'avais essayé et cela m'indiquer impossible de charger la ressource file:/D:/..../apiJni.dll ...
Du coup, j'ai cherché comment faire et je suis tombé sur http://docs.oracle.com/javase/1.4.2/...html#resources voir chapitre "resources Element"

Sinon, pour le location, j'ai "C:\externalJars\...\". En bref, le répertoire que j'ai sur mon serveur et qui est indiqué dans mon lanceur JNLP (<jar href="externaljars/.../apiJni.jar/>)

Aussi, autre question (je suis en train de chercher mais si tu as la réponse ça me fera gagner du temps) => comment indiqué le log4j.xml utilisé par mon api JNI ?
(Pour l'instant, j'ai ajouter au lanceur JNLP <property name="log4j.configuration" value="./log4j.xml" /> mais ça ne fonctionne pas mieux)

[fxrobin]

De mémoire, parce que je n'ai plus le projet sous les yeux il me suffisait simplement de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
System.loadLibrary("monfichier"); // lecture de "monfichier.dll" : note ne pas mettre .dll

et comme c'était une ressource du JNLP, pas de soucis.

tiens, regarde ce lien :
http://lopica.sourceforge.net/faq.html#native

et ça aussi :
http://lopica.sourceforge.net/ref.html#nativelib

Bon finalement, je ne me souviens plus si je l'avais mis à la racine d'un JAR ou pas ... il me semblait que non ... mais vus les liens que je viens de te donner il faut mettre tes dll dans un JAR.


Pour log4j.xml ... il ne le voit pas quand il est à la racine du JAR de ton applet ?

[maverick5051]

J'avais vu l'utilisation du System.loadLibrary mais je n'ai pas essayé car, ici, je n'ai pas la main sur l'api et, du coup, je ne peux changer le code en faisant un System.loadLibrary() à la place du code de l'api.
D'autre part, en admettant que je fasse ce System.loadLibrary() dans mon applet, rien d'empêcher le fait que le code de l'api s'exécute et me renvoie une erreur du fait qu'il va chercher la dll à un certain endroit.

Je pense à une autre solution =>
1- dans le lanceur JNLP, j'indique un jar contenant mon jar avec mes 2 DLLs.
2- dans mon applet, je déjarre ce jar dans le répertoire où se trouve mon jar api
Qu'en penses-tu ?
D'ailleurs, y'a peut être une option JNLP permettant de faire cela ??

Pour le log4j.xml, je l'ai rajouté dans le jar de mon applet ainsi que dans le répertoire possédant le jar => dans les 2 cas, ça ne fonctionne pas (ce qui me paraît vraiment bizarre) => je vais essayer en mettant un log4j.properties, on ne sait jamais

[tchize_]

a mon avis, avec jnlp, tu devrais te contenter d'un System.load("talibrairie")

[maverick5051]

Sauf que le System.load(libraryName) ne va pas suffir, non ?

L'api, en exécutant le code suivant va me renvoyer un UnsatisfiedLinkError

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
String libName = System.mapLibraryName("jniApi");
File libFile = new File(location, libName);
if(!libFile.isFile())
throw new UnsatisfiedLinkError("jniApi not found");

J'ai tort ?

[fxrobin]

oui sûrement, parce que File c'est forcément une ressource locale.
C'est cette "API" sur laquelle tu n'as pas la main qui risque effectivement de poser problème.

Tu es obligé de lancer cette portion de code ?
Si tu charges la DLL avec loadLibrary toi même, est-ce que cela te permet d'utiliser le reste de ton API ?

[maverick5051]

La portion de code est en static dans la classe de mon api malheureusement => donc je suis obligé de passer par là.

Après je pourrais éventuellement catcher l'exception et continuer mon traitement ??? Ce n'est pas très beau mais je vais tenter le coup ...

[tchize_]

Nope, catcher ne résoudra pas ton problème là. Si c'est un bloc static, l'exception passer par le classloader avant d'arriver à toi et le classloader marque la classe comme inutilisable, et coic.


Un solution pourave serait d'aller voir quel est le dossier mentionné par le File, et, avant de charger ta librairie, d'y copier la dll dans le répertoire attendu C'est moche et remoche

[maverick5051]

Ah, merci pour cette réponse. Vu que j'avais plusieurs solutions à tester, cela m'en élimine une

Le fait de copier mes dll dans le répertoire où se trouve mon jar api sur le poste client était une autre solution que j'avais envisagé et que je vais désormais approfondir.
Par contre, quand tu dis "dossier mentionné par le file", qu'est ce que tu veux dire ?

En fait, je pense qu'il faut que je trouve le moyen d'installer dans un même répertoire sur le poste client, le jar api ainsi que mes dlls. Je ne comprends pas trop pourquoi le lanceur JNLP ne propose ce type d'options mais bon ... A moins que j'ai loupé qqchose ????

[tchize_]

Par contre, quand tu dis "dossier mentionné par le file", qu'est ce que tu veux dire ?

Celui que ta librairie calcule sous le nom de "location" Elle calcule un truc, tu fais le même calcul et t'y copie la dlls. C'est moche

Je ne comprends pas trop pourquoi le lanceur JNLP ne propose ce type d'options mais bon ...

Parce qu'une librairie conçue correctement ne fais pas la tambouille que fais ta librairie . Le lanceur jnlp fait ce qui est standard, a savoir amener ta dll dans le "library path" de l'application, library path qui est l'endroit que la jvm utilise par défaut pour charger les dlls / .so additionels.

[fxrobin]

En fait, je pense qu'il faut que je trouve le moyen d'installer dans un même répertoire sur le poste client, le jar api ainsi que mes dlls. Je ne comprends pas trop pourquoi le lanceur JNLP ne propose ce type d'options mais bon ... A moins que j'ai loupé qqchose ????

j'ai peut-être une idée.
Avant de lancer "ta" librairie, copie (via InputStream / OutputStream) la DLL qui est dans le JAR (getResourceAsStream) pour la mettre dans le répertoire temporaire de l'utilisateur (propriété de la classe System). Ensuite donc tu as ta "location" que tu peux donner à ton API (par exemple "d:\temp\madll.dll") ... et donc commencer à lancer réellement ton applet "métier".

C'est "moche, archi-moche" comme dirais Tchize , mais je pense que ça marcherait.

[maverick5051]

Pour le location de mon api, je ne peux pas jouer dessus malheureusement.
Pour la copie des DLLs, c'est ce que je fais actuellement par la méthode que tu indiques.

Ce que je souhaite faire (au mieux), c'est :
En admettant que apiJni.jar et nativeLib.jar sont téléchargés dans le même répertoire destination sur le poste client:
1- Récupérer le répertoire de destination des téléchargements sur le poste client
2- Unjaré (au moyen de InputStream/OutputStream comme l'indique fxrobin => ça marche très bien) mon nativeLib.jar dans ce répertoire

Normalement, cela devrait fonctionner mais (parce qu'il y a toujours un mais ) comment puis-je récupérer le répertoire destination de mes téléchargements sur le poste client ? Est-ce possible ?

[fxrobin]

Normalement pas besoin de savoir où le JAR est puisqu'il est déclaré en ressource. dans le JNLP.

Donc un this.getResourceAsStream("monfichier.dll") t'ouvre un InputStream dessus et tu pourras mettre la DLL où tu veux.

Au pire tu récupères ta DLL avec une "bonne vieille" connexion HTTP dans ton applet que tu écris là où tu veux sur le disque de l'utilisateur. Dans ce cas, utilise Commons HttpClient, c'est plus simple.

[maverick5051]

Le this.getClass().getResource() me retourne null (je suis dans le code de mon applet) => es-tu sûr de ton coup ?

De plus, mes dlls doivent être incluses dans un jar pour que JNLP fonctionne.
En gros, dans mon JNLP, j'ai une ligne nativelib dans resource pointant vers un jar incluant mes dlls.
Du coup, je fais un this.getClass().getResource("apiJni.jar") pour récupérer le jar que je unjar par la suite

Dites, sinon, je viens de trouver ça => http://jnlp.sourceforge.net/netx/news.html

Avez-vous déjà utilisé ? J'ai l'impression que je peux trouver de l'aide là-dedans ...

[fxrobin]

le nom de fichier dans getResourceAsStream est donné soit de manière absolue (en commençant par "/"), soit de manière relative par rapport à la classe d'où tu l'invoques.

[maverick5051]

Pas mieux ???

[fxrobin]

J'essaierai de te faire un PoC mais là je n'ai pas trop le temps d'ici à ce week-end.

[maverick5051]

Bon, j'avance un peu.

Je viens de décrouvrir netx => http://jnlp.sourceforge.net/netx/news.html

Et c'est franchement génial. En faisant seulement ce petit bout de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
JNLPRuntime.setDebug(true);
JNLPFile jnlpFile = null;
try {
   String url = getCodeBase().toExternalForm() + "AgentCom.jnlp";
   jnlpFile = new JNLPFile(new URL(url));
} catch (ParseException e) {
   e.printStackTrace();
}
JNLPClassLoader jnpClassLoader = JNLPClassLoader.getInstance(jnlpFile, new UpdatePolicy());

J'obtiens tous mes livrables sur le poste client ....
Maintenant, il me reste à copier mes DLLs au bon endroit ...

[tchize_]

En gros, si je suis bien, t'es parti pour faire une applet, qui embarque un javawebstart, ui va lancer le jnlp concerné