Chargement de dll à moitié réussi - Java - Programmation
Marsh Posté le 22-10-2003 à 17:50:44
j'ai trouvé... il ne cherche pas la dll dans le .jar, mais dans un répertoire...
désolé du dérangement
PS : est-ce possible de dire à la JVM de charger la dll dans le .jar de l'applet ?
Marsh Posté le 22-10-2003 à 17:52:58
Essaie de mettre le jar dans le java.library.path sinon je sais pas
Marsh Posté le 22-10-2003 à 17:56:58
Taiche a écrit : Essaie de mettre le jar dans le java.library.path sinon je sais pas |
sauf que le jar est chargé au chargement de l'applet... à priori on sait pas où il est stocké. y'a une méthode pour le savoir ?
Marsh Posté le 24-10-2003 à 09:32:36
oui
on doit développer un système client/serveur sur internet, et mon prédécesseur n'a rien trouvé de mieux que d'utiliser les sessions HTTP 1.1 pour se faciliter la tâche
ce qui fait que maintenant on est obligé de faire tourner en applet dans un navigateur
si tu as une solution pour me débarrasser rapidement des sessions, je suis preneur, mais bon j'y crois pas trop
Marsh Posté le 24-10-2003 à 10:30:56
Predicator a écrit : on doit développer un système client/serveur sur internet, et mon prédécesseur n'a rien trouvé de mieux que d'utiliser les sessions HTTP 1.1 pour se faciliter la tâche |
bin tu peux faire de l'HTTP dans un client standalone hein
Marsh Posté le 24-10-2003 à 10:35:44
Ouais, parce que, du JNI dans une applet, à mon avis, ça serait un p'tit peu limite niveau sécurité (euphémisme).
Marsh Posté le 24-10-2003 à 10:44:50
El_gringo a écrit : Ouais, parce que, du JNI dans une applet, à mon avis, ça serait un p'tit peu limite niveau sécurité (euphémisme). |
certes... l'applet sur le net ne se sert pas des JNI.
l'idéal serait de pouvoir me débarrasser des sessions comme dit Dark_Lord... le problème c'est que j'ai très peu de temps pour le faire, donc si c'est long, faudra laisser tomber.
vous avez un truc (hors tuto java, bien fait mais trop lent) qui explique comment émuler les sessions en Java ?
sinon le JNI est utilisé par l'applet là où on aurait voulu en faire une application. c'est devenu une applet signée avec des dll embarquées.
Marsh Posté le 24-10-2003 à 10:48:06
putain mais qu'est-ce que c'est con d'utiliser HTTP pour du client serveur de base
tu mettras 3 claques a ton prédécésseur de ma part.
y'a des outils pour faciliter ca, c'est pas pour les chiens
Marsh Posté le 24-10-2003 à 11:08:18
lorill a écrit : putain mais qu'est-ce que c'est con d'utiliser HTTP pour du client serveur de base |
si je l'avais sous la main je l'aurais déjà fait
[citation]y'a des outils pour faciliter ca, c'est pas pour les chiens
[/citation]
comme ?
Marsh Posté le 24-10-2003 à 11:10:25
Heu si non j'ai du code pour charger une bibliothéque dynamqiue à partir d'un jar si tu veux.
Marsh Posté le 24-10-2003 à 11:11:23
Predicator a écrit : |
http://lucane.org
(bon, y'en a surement d'autres, mais je connais pas trop en fait. une recherche sur client server platform/tool devrait aider, sauf que dans ton cas précis t'es un peu bloqué)
Marsh Posté le 24-10-2003 à 11:11:45
LetoII a écrit : Heu si non j'ai du code pour charger une bibliothéque dynamqiue à partir d'un jar si tu veux. |
chuis preneur
Marsh Posté le 24-10-2003 à 11:15:23
LetoII a écrit : Heu si non j'ai du code pour charger une bibliothéque dynamqiue à partir d'un jar si tu veux. |
Un code écrit en Java qui est capable de faire ça ?
J'suis preneur aussi!
Marsh Posté le 24-10-2003 à 11:17:29
ReplyMarsh Posté le 24-10-2003 à 11:18:38
lorill a écrit : |
Code :
|
Voilà, en théorie ça passe quelque soit la plateforme, mais j'ai pu tester ça que sous windows. Il faut que le jar soit dans le classpath bien sûr
Marsh Posté le 24-10-2003 à 11:21:19
ReplyMarsh Posté le 24-10-2003 à 11:22:29
Predicator a écrit : |
ca c'est pas un probleme hein... tu précises le classpath de ton applet via la balise, ou alors direct dans le premier jar de l'applet avec le manifest.
Marsh Posté le 24-10-2003 à 11:22:33
Predicator a écrit : |
Ben pas vraiment, si tu déploie ton truc dans un jar t'as juste à coller la biblio dans le jar avec le reste des classes (c ce que je fais)
Marsh Posté le 24-10-2003 à 11:23:43
lorill a écrit : c'est de toi ? on peut le reprendre tel quel ? |
Ouai tu peux, t'as juste une variable statique à définir et à coller ça ou tu veux dans la classe qui a besoin de la biblio
Marsh Posté le 24-10-2003 à 11:29:16
lorill a écrit : |
alors c'est moi qui doit être ignard
éclirez ma lanterne svp... quand on charge une applet dans un .jar, on peut dire où cette archives doit être mise ?
Marsh Posté le 24-10-2003 à 11:30:53
Predicator a écrit : |
non, mais ca utilise le classloader du navigateur (enfin du plugin java), donc ca n'a rien a voir avec la variable d'environnement.
Marsh Posté le 24-10-2003 à 11:37:10
Predicator a écrit : |
Marsh Posté le 24-10-2003 à 11:41:57
Predicator a écrit : |
Quand tu utilise un jar le class path est le fichier jar lui même. D'ailleur c assez con par ce que java -jar le_jar -cp le_chemin il s'en fou comme de l'an 40 du chemin rajouté au class path
Marsh Posté le 22-10-2003 à 17:41:55
Bonjour...
j'ai un problème qui me rend fou
j'ai crée 2 classes JNI :
à côté j'ai généré 2 dll associées, quasi vides... il y a juste les fichiers générés par JNI dedans... ensuite je teste le bousin :
le truc, c'est qu'il me balance l'erreur :
les dll sont identiques au niveau du code.
les 2 dll sont bien dans le jar de l'applet.
l'applet est bien signée.
l'utilisation seule de RECOCarChi marche.
l'ordre de System.loadLibrary ne change rien.
si je charge RECOCarLet dans JNIChiffreRecognizer et RECOCarChi dans JNILettreRcognizer, il plante toujours sur la même librairie...
je ne vois vraiment pas d'où ça peut venir
vous avez une idée ?
merci
Message édité par Predicator le 22-10-2003 à 17:45:50