Accès aux librairies locales à partir d'une applet [Résolu]

[maverick5051]

Bonjour à tous,

Projet:
Sur le poste client, j'ai des jars qui sont installés dans un répertoire donné
A partir du navigateur, j'accède à une appli web client léger dans laquelle j'ai un applet.
J'aimerais que mon applet utilise les jars présents sur le poste client.

est-possible de faire référence, à partir d'un applet, à des librairies présentes sur le poste d'exécution ?
Si oui, de quelle façon ? (fichier Manifest, ...)
Y'a t'il possibilité d'utiliser les variables d'environnement du poste client ? (l'idée serait d'avoir une variable d'environnement faisant référence au répertoire du poste client utile pour mon applet et de faire référence à cette variable d'environnement dans mon applet)

Précision => mon jar est signé, je peux, donc, à priori, accéder aux ressources locales

Merci de vos réponses

[tchize_]

Quel est le but de l'opération? Pourquoi vouloir accéder à des librairies locales (dont tu ne peux pas être sur de la version, de l'emplacement ou même de l'existence) plutot que de l'inclure dans l'applet?

On pourrais résoudre ton problème en instanciant un classloader qui inclue ces jar et en appelant des classes dans ce classloader. Mais ce serait inutilement complexe et sujet à erreurs.

[fxrobin]

D'accord avec Tchize.

Et je dirai même plus, c'est que tes JAR sont conservés en cache dans le loader local JAVA, donc niveau temps de téléchargement, ça ne pose pas de problème.

[maverick5051]

En gros, j'ai un périphérique sur le poste client avec lequel je dois communiquer. Pour une cela, une api est fourni avec ce composant (JNI) et est donc installé sur le poste.
Je précise que ce module (API+périphérique est livré par une équipe externe).

Maintenant, mon but est de faire communiquer ce périphérique avec mon appli web (interaction sur la cinématique).

Y'a peut-être mieux qu'un applet pour faire cela mais l'avantage de l'applet, c'est que:
- je n'ai rien à installer sur les différents postes clients
- facilité d'impact sur la cinématique via JSObject
Une autre solution pourrait être une appli Java Web Start à télécharger sur le poste mais là, c'est plus compliqué pour impacter la cinématique

Autre idée ?

Sinon, pour le Classloader, j'ai essayé après avoir vu cette page http://stackoverflow.com/questions/9...-signed-applet mais non concluant. Après, est-ce que j'ai bien mis en place la solution ????

Perso, je pensais plutôt à une solution de type "modification du manifest.mf" afin qu'il attaque, via une variable d'environnement prédéfinie, les jars en local mais je n'ai pas l'impression qu'une telle possibilité existe ...

Voili

[tchize_]

j'ai eu exactement la même situation (JNI + applet) à gérer (il s'agissait de lire des données d'une carte beID à partir d'une applet). La solution a été de mettre le jar (contenant les classes natives) avec l'applet et n'était nécessaire sur le poste client que les dll de la partie native. Ces dlls étaient dans le répertoire système ce qui fait que le loadlibrairy dans le jar fonctionnait sans soucis. Donc en pratique, une fois que l'appli marchait en mode desktop, j'ai plus eu qu'à tapper tout les jar, y compris ceux du lecteur, dans l'applet


Attention cependant. La JVM ne peux charger qu'une seule fois une librairie dll. Or ton applet étant dans une page web, elle va

-> démarrer plusieur fois
-> Avoir plusieurs classloader référencant et tentant de charger la librairie native
-> cette dernière va probablement, à chaque fois, appeler loadlibrary.

Conséquence: Ca peux cracher lors de la seconde visite de la page avec l'applet.

Un autre option, si peu de postes sont concernés, serait d'aller tapper les librairies native dans le dossier endorsed/ de la jre pour que toutes les applications y aient accès... avec les conséquences que cela implique.

Troisième possibilité, si la page web n'est pas indispensable, c'est jnlp, qui permet d'inclure les librairies native dans le déploiement.

[fxrobin]

j'ai eu la même chose à faire avec un lecteur de code barre qui s'appuyait sur une DLL.

Cette DLL était simplement déclarée dans les ressources de l'Applet lancée au moyen d'un lanceur JNLP (merci JAVA 6) et la DLL était située dans le même répertoire que le .jar de l'applet sur le serveur. Et ça fonctionnait très bien.

D'ailleurs ici il y a la réponse :
http://www.developpez.net/forums/d90...va-charge-dll/

et enfin, une autre façon de faire ici :
http://www.jguru.com/faq/view.jsp?EID=468498

Pour faire qu'une applet se lance par JNLP :
http://docs.oracle.com/javase/tutori...ingApplet.html

[maverick5051]

Merci pour vos réponses très instructives => je vais plancher maintenant

Pour répondre aux interrogations de tchize_, je ne vais pas avoir le problème de plusieurs démarrages.

En fait, je serais dans un contexte type borne avec un lecteur de carte.

Mon idée est d'intégrer dans une page :
- mon applet (invisible)
- un iframe pointant vers mon appli web
Mon applet interagissant sur l'appli web présente dans l'iframe.
Cette page ne pourra pas être fermé (et donc pas réouverte => lancement de iexplore -k avec suppression des touches clavier CTRL+ALT) => donc une seule ouverture de l'appli web par poste => donc pas de problématique de plusieurs classloader ....

[fxrobin]

si ton applet discute avec le serveur et met des choses en session, il faudra que ton applet envoie des requêtes HTTP avec le JSESSIONID. Et donc ton applet devra se démarrer avec le JSESSIONID en paramètre.

En tout cas c'est comme cela que j'avais fait pour mon lecteur de code barre.

[maverick5051]

Ce qui est prévu, c'est que mon applet appelle des méthodes javascript présentes dans l'appli web avec passage de paramètres (données lues sur la carte) via JSObject
Les méthodes javascript sont chargées, ensuite, de gérer le contexte et la cinématique de mon appli web à partir des paramètres envoyés par l'applet

Est-ce que cela répond à ton questionnement ?

Je ne suis pas un expert technique sur le sujet. Par exemple, JsessionId => kezako ?

[fxrobin]

JSESSIONID c'est l'identifiant de session.
Ca sert quand un utilisateur est connecté et identifié.
Ca sert à conserver la session de l'utilisateur (sorte de Caddy)
Pour ma part j'y mettais les "scan codes" de mon lecteur pour validation l'écran web suivant.

[maverick5051]

OK, je me doutais que cela pouvait être un id de session http => le 'J' devant me gênait un peu

[maverick5051]

Bon, je viens de faire mes tests via l'URLClassLoader.
Pour cela j'ai initialisé une variable d'environnement sur mon poste pointant vers le répertoire où se trouve mes librairies et j'arrive à attaquer mon api (via invoke).

Maintenant, ce qui me pose problème, c'est que la classe attaquée utilise, par exemple, Log4j et que, donc, je dois intégrer le jar de log4j dans mon ClassLoader.
Et forcément, ce n'est pas la seule librairie dont j'ai besoin ....

N'y aurait-il pas une solution pour éviter de détailler le chargement de chaque jar dans mon ClassLoader et aussi de chaque classe utilisée par l'api ?

[fxrobin]

Tu t'es lancé dans la solution la moins simple, je trouve.
Un pauvre lanceur JNLP et la .DLL qui accompagne ton jar de ton applet dans le même répertoire sur le serveur et c'était fini ...

[tchize_]

effectivement, la solution de fxrobin est la plus simple (n'existait pas quand j'ai du attaquer ce problème il y a 6 ans)
La deuxième est de prendre simplement le jar natif comme n'importe quel autre jar de ton application (et avoir tes dlls dans System32)
LA troisième, la plus compliuée, est celle que tu as tenté

[maverick5051]

Ouais mais j'aime bien me faire du mal

Sérieusement, je vais plancher sur cette solution.

En attendant, vu que j'aime bien comprendre quand ça ne marche pas, avez-vous une idée sur ce problème ? :

Rappel => mon applet attaque des jars en local qui attaquent eux-mêmes une dll. Cela se fait via le ClassLoader (utilisation d'une variable d'environnement pour trouver le chemin de mes jars sur je poste client).
D'autre part mon jar contenant l'applet est signé.

Lorsque j'exécute mon applet, j'accède bien au service de mon jar du poste client mais le problème est que, dans ce jar, il y a l'exécution de ApiJNI.getProtectionDomain().getCodeSource().getLocation(); et je me prends une exception sur cette ligne :
Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getProtectionDomain")

Cela me surprend => du fait que mon applet est signé, je pensais que tout ce qui était exécuté dans la JVM de mon applet était ok pour les accès postes client (d'ailleurs ça fonctionne bien avec le jar de mon api)

Faut-il que les jars du poste client soient signés aussi ?????

[tchize_]

et oui, faut que tout soit signé.

Le securitymanager est toujours actif et, à chaque demande, il va simplemenr vérifier que le demandeur ainsi que la chaine d'appel sont signé.

Pour rendre les choses encore plus vaches, quand du javascript appelle une méthode d'une applet, la partie javascript est naturellement non signée et du coup le security manager t'envoie aussi pêter

[maverick5051]

Yes, yes, yes et re-yes.

Un grand merci à vous.

Au final, j'ai utilisé un lanceur JNLP dans lequel je fais référence à mes différents jar et ça marche du feu de Dieu

Je confirme que le lanceur JNLP par rapport à l'URLClassLoader, c'est vachement plus facile.

[tchize_]

N'oublie pas la bouton si c'est réglé

[fxrobin]

"j'adore quand un plan se déroule sans accroc"

H. Smith.

[maverick5051]

Bon, finalement, j'ai un autre petit souci.

J'ai installé un serveur http sur mon poste puis, j'ai attaqué depuis un poste client ma page web contenant mon applet.

Là, j'ai un souci => j'ai un retour UnsatisfiedLinkError lors du chargement de mon applet

Mon applet utilise l'api livrée avec le lecteur de carte. Cette api utilise des DLLs en exécutant le code suivant :
URL codeURL = fr/pck/api/ApiJNI.getProtectionDomain().getCodeSource().getLocation();
String location = URLDecoder.decode(codeURL.getFile(), "UTF-8");
location = (new File(location)).getCanonicalFile().getParentFile().getAbsolutePath();
String libName = System.mapLibraryName("jniApi");
File libFile = new File(location, libName);
if(!libFile.isFile())
throw new UnsatisfiedLinkError("jniApi not found");
String path = libFile.getAbsolutePath();
System.load(path);

Je rappelle que je n'ai pas la maîtrise sur le code de l'api.
En fait, pour loader les DLLs, il cherche le chemin de celle-ci en utilisant le chemin de l'api.

J'ai fait un essai en ajoutant dans mon lanceur JNLP un nativelib pointant sur un jar contenant mes 2 DLLs, mais non concluant

Avez-vous une idée, svp ?