[JAVA]: Applet, "native library" ed errore "UnsatisfiedLinkError"

[dannie]

java.lang.UnsatisfiedLinkError: Native Library xxx already loaded in another classloader

è da stamattina che mi scontro con questo errore, inizio ad essere disperata.... spero tanto che qualcuno di voi mi sappia aiutare!
In pratica ho un'applet che utilizza una classe che fa una System.load(qualcosa); quest'applet è inclusa in tutte le pagine della mia applicazione web. Se apro la prima pagina della mia applicazione web funziona a meraviglia; appena passo alla seconda pagina però, l'inizializzazione dell'applet fallisce e in console leggo l'errore che vi ho riportato (è in fase di inizializzazione che si tenta di caricare la native library).
Ho cercato un po' in rete, ho anche trovato questo , ma vi confesso di non aver capito troppo bene qual'è il problema... o meglio, correggetemi se sbaglio, ma mi sembra di aver capito che ogni volta l'applet venga caricata da un classloader differente e non sia possibile ricaricare la seconda volta la native library in quanto caricata dal precedente classloader... quindi? Come posso fare per far funzionare correttamente l'applet in tutte le pagine? Ho provato alcune delle soluzioni suggerite, ma evidentemente non bene perchè non sembrano funzionare....
[NOTA] L'applicazione è su JBoss e i jar (quello dell'applet e quello utilizzato dall'applet) sono firmati....

[dannie]

up

[Andrea1979]

Leggendo tutte le risposte, sembra che questa sia stata apprezzata

 Gandalf_the_black

Hello applet fans.
As you know the solution of putting the jar file in classpath only works for server side programming. When deploying multiple web apps that uses the same applet on multiple pages the problem still exist. However I have found a solution. The trick is to avoid multiple classloaders. And that can be done by controlling the codebase. Each new codebase gives a new classloader. In the Java Console you can list the classloaders (press 'l') and see their code base. To make sure all applets are loaded by the same classloader put the jar archive in a common place on the server and in all applet tags set the codebase attibute to point to this location. E.g. 
<applet name="myApplet"
	code="com.xxx.MyApplet"
	codebase="http://localhost:9080/Common/myapplets"
	archive="http://localhost:9080/Common/myapplets/myarchive.jar" 
	width="350" height="150"	
	mayscript>
	<param name="cabbase" value="/Common/myapplets/myarchive.cab">
</applet>

[dannie]

Ciao Andrea1979 e grazie per aver risposto.
Infatti avevo visto quell'intervento e ho provato a seguirlo ma non ho ottenuto grossi risultati.... O meglio, che cosa si intende per punto comune? Sembrerebbe, a vedere l'esempio, che l'applet venga messa in un'unica applicazione da cui eventualmente tutte le altre applicazioni la prendono... ma nel mio caso ho un'unica applicazione, in cui l'applet viene richiamata in tutte le pagine. Ho cque provato a mettere l'applet sia in una applicazione "esterna" a quella interessata, sia a metterla in una cartella virtuale del server (cioè una cartella al di fuori di ogni applicazione ma accessibile con un particolare indirizzo web). Nel secondo caso ho ottenuto un risultato parziale: prima ottenevo l'errore in tutti i casi successivi alla prima esecuzione dell'applet, ovvero se aprivo la prima pagina e poi ne facevo il refresh ottenevo subito l'errore; in pratica l'errore si verificava per ogni richiesta successiva alla prima (era necessario chiudere il browser). Spostando l'applet nella cartella virtuale sembra che l'errore si verifichi per ogni pagina successiva alla prima (anzichè per ogni richiesta): se faccio il refresh della prima pagina non ottengo errori, ma se tento di passare a un'altra pagina l'errore si ripresenta. O almeno, questi sono i risultati che mi sembra di ottenere fra tutti i vari esperimenti....
Ho visto fra gli interventi un post simile a quello citato da te, in cui si parlava di una cartella condivisa del server: "Shared" per Tomcat..... Leggendo un po' di documentazione, mi sembra che potrebbe essere un'idea sensata ma non mi è chiaro come potrei poi richiamare l'applet: che indirizzo do come codebase? Inoltre, non ho ancora capito qual'è la cartella equivalente per JBoss (usa Tomcat ma non ha la stessa suddivisione di cartelle), ma questo è un altro discorso, al massimo vado per tentativi...
E ora aggiungo una cosa, che per me è quasi una beffa: la stessa applet messa in un'applicazioncina di prova, con tre pagine in croce giusto per provare, funziona senza problemi, ora che tento di integrarla in un'applicazione "vera" dà quest problema che sembrerebbe invece "comune".... eppure tra l'applicazione di prova e quella reale non ci sono enormi differenze, se non appunto la dimensione dell'applicazione e la complessità delle pagine, ma questi non dovrebbero essere fattori determinanti per un componente "a sè" come un'applet... o no?
Preciso che non ci sono altre applet, è l'unica... e personalmente è anche la prima su cui metto le mani, per questo spero nel vostro aiuto!

[Andrea1979]

Premetto che non mi sono mai trovato a caricare librerie native da una Applet, per cui, tutto quel che "so" in tal proposito è quello che ho letto in internet e non si basa quindi su esperienza personale diretta di programmazione.

Detto ciò, potresti postare il codice HTML di due pagine diverse della tua applicazione per vedere come carichi l'applet?

[dannie]

Certo, eccole! (beh, direi solo la parte interessata, le pagine sono abbastanza lunghe!)
Questa è la prima pagina dell'applicazione, una pagina di login, che interagisce attraverso l'applet con un lettore di smart card (ecco il perchè della native library) permettendo il login con la smart card:

<td width="35%" align="top">
  <applet code="myApp.smartcard.auth.SCApplet.class" archive="/myApp/scapplet.jar;jsessionid=D353A70030731D639AE8D85543ABBB5F" width="200" height="150">
    <PARAM NAME="loggedURL" VALUE="/myApp/actions/ReadMenu.do;jsessionid=D353A70030731D639AE8D85543ABBB5F?id=0&caption=Main"/>
    <PARAM NAME="certificateURL" VALUE="/myApp/form/certificate.jsp;jsessionid=D353A70030731D639AE8D85543ABBB5F">
    <PARAM NAME="challengeURL" VALUE="/myApp/form/getchallenge.jsp;jsessionid=D353A70030731D639AE8D85543ABBB5F">
    <PARAM NAME="responseURL" VALUE="/myApp/form/sendresponse.jsp;jsessionid=D353A70030731D639AE8D85543ABBB5F">
  </applet>
</td>

Se l'autenticazione va a buon fine si passa alla pagina principale, in cui l'applet continua ad essere presente per permettere il logout: il codice è identico a quello appena postato.
In questa versione il jar è nell'applicazione quindi in realtà basta aprire la prima pagina e fare refresh per vedere l'errore.
Ho provato anche a usare codebase ma non è cambiato nulla.
Ed ecco anche la paginetta dell'applicazione di test:

<body>
  <applet code="myApp.smartcard.SCApplet.class " archive="scapplet.jar" width="200" height="150"> 

  </applet> 
</body>

In questa versione ci sono anche diversi parametri in meno ma avevo fatto delle prove con i parametri anche nella applicazione di test.

Confesso di essermi concentrata più sull'aspetto di configurazione dell'applicazione che sull'applet in sè: dici che non la sto richiamando correttamente?

[dannie]

Uhmmm... notando i jsessionid, non è che il problema può avere a che fare con qualche gestione della sessione? Nessuno ha mai avuto questo genere di problema?

[dannie]

Più leggo nel forum della sun (ho visto che è un problema su cui ci sono lamentele praticamente da sei anni e a cui la sun continua a rispondere che non è bug ma una limitazione nota e voluta) più mi convinco che il problema sia proprio legato al fatto che l'applet viene caricata ogni volta su un diverso classloader.... quindi le soluzioni possono essere:

• usare i frame.... ma preferirei caldamente evitarlo...
• fare in modo che l'applet venga caricata sempre nello stesso classloader, ma non saprei come... può avere a che fare con una particolare gestione della sessione? dopotutto nell'applicazione di prova tutto sembra funzionare, quindi in qualche modo il problema è stato bypassato...
• ...qualche altra scorciatoia? se io avessi il jar in locale sul client cambierebbe qualcosa? meccanismi come le java extension possono essere utili in questo caso?

Io continuo a cercare e provare, se avete suggerimenti...

[Andrea1979]

ciao, allora, ho visto che nei due codici html risultanti ci sono delle differenze: il refierimento all'id di sessione che sparisce nel successivo caricamento. In particolare, che succede se eviti di stampare al primo caricamento l'id di sessione in archive?

[dannie]

In realtà quegli id di sessione sono stampati automaticamente dal <c:url />, mi risulta siano (ma forse lo sai meglio di me) un modo per tracciare al sessione in caso di cookie disabilitati. Ho provato a togliere i <c:url /> e i jessionid sono spariti ma non sembra essere cambiato nulla.....
PS Grazie tante per il tuo interessamento!!