Newsgroup: it.comp.java
Titolo: Problema Tomcat ed RMI

Scusate se sono pedante ma ripropongo un problema perchè sono un po' "alla
frutta"...
1) Scrivo un programmino che istanzia un po' di classi remotizzabili che
gestiscono dei tread (per fare della roba...); questo programmino crea un
RMI-Registry e registra queste classi in esso.
2) Un applet deve poter accedere all'interfaccia remota di quelle classi,
quindi una volta ottenuti gli skeleton grazie ad un accesso all'
RMI-Registry attiva i metodi delle suddette classi in remoto.
3) L'applet del punto precedente non funzionava dando errore:
java.net.SocketPermission... dopo una ricerca su internet ho usato un file
xyz.policy per aumentare i permessi del Java (= liberare gli accessi ai
socket), e così ha funzionato tutto.
4) PERO' io DEVO passare attraverso un Server... mi spiego meglio: l'applet
di cui sopra QUANDO viene lanciato da una normale pagina HTML funziona
benissimo; SE, invece, viene lanciato da una "pagina" Servlet (di Tomcat,
per la precisione) riprende a generare l'errore java.net.SocketPermission
5) In pratica una pagina HTML porta l'utente verso una Servlet di Tomcat,
questa Servlet invia al Browser la stessa linea di "codice HTML" che attiva
l'applet che io uso nella "pagina HTML funzionante", ma, in questo secondo
caso, l'applet, una volta attivatosi, non riesce ad accedere all' RMI...
inviando il solito errore:
java.net.SocketPermission (IP : Porta, connect,resolve)
6) A questo punto sono andato nel file *catalina.policy* (file di
configurazione della sicurezza di Tomcat) ed ho aumentato le proprietà
d'accesso (= abbassato la sicurezza) dei vari socket; ma questo non ha
prodotto risultati.
Domande:
- Questo problema dipende dalla gestione dei contesti (context) di Tomcat ?
- Oppure è la "restrizione standard sugli accessi" che i Server Jakarta
operano sugli applet ?
- SE è Tomcat a bloccare l'accesso al socket, come faccio per sbloccarli ?
- Avete idee alternative per gestire un JNDI-RMI dentro un server
(considerando che i context di Tomcat sono read-only...) ?
- Che io debba "autenticare" l'applet presso Tomcat con una firma digitale ?
- Aiuto !

Mi dispiace se non riesco a dare una soluzione specifica al tuo problema, in generale se
il server RMI e il Tomcat sono sullo stesso server dovrebbe funzionare tutto; non funziona
invece se si trovano su macchine diverse (anche con nome diverso).
Comunque, usare RMI con un applet e' "transitabile" solo se sei su una intranet: per
internet (o anche per intranet grosse) ti consiglio di usare HTTP+Servlet. Se vuoi
qualcosa gia' fatto che funge (in produzione) ed e' molto simile ad RMI (ma si basa su
HTTP) puoi usare il mio vecchio GMI, che trovi sul mio sito web:
http://digilander.libero.it/bbossola/gmi.html
C'e' un bel compilatore che ti crea un proxy da usare sull'applet (equivalente allo stub
di RMI) e una servlet da posare su tomcat (equivalente allo skeleton di RMI) che invoca i
metodi del tuo oggetto contenente la logica di business. Il tutto funziona in modo
trasparente: l'applet invoca il metodo A del proxy, questo viene trasformato in una
richiesta HTTP che viene passata alla servlet che invoca il metodo A dell'oggetto di
business. Dovrebbe essere semplice, c'e' anche un mini-tutorial in italiano.
Fammi sapere, nel caso scegliessi questa strada, se ci sono problemi.
Ciao,
    Bruno.
-- 
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
| Membro del JUG Torino - 
http://www.jugtorino.it

     Bruno.
Ti ringrazio immensamente dell'aiuto, Bruno... *però* (c'è SEMPRE un però).
Praticamente quello che devo realizzare è un'asta informatica in tempo
reale; nella realizzazione di questo progetto (che è la mia TESI di laurea
!!!) sono FOCALI i tempi di risposta del sistema.
Per questo motivo ho cercato di ridurre al minimo le "tare dei tempi"; cioè
una connessione HTTP implica (se non erro) una richiesta al server, un
passaggio di info sui socket, passaggi di context ecc. ecc. se ad ogni
invocazione di metodi (e ce ne potrebbero essere complessivamente fino ad un
centinaio al secondo... e bi-laterali server --> client e contemporaneamente
client --> server) dovessi attivare una richiesta http credo che il sistema
collasserebbe sotto un carico infimo di utenti ed aste... se poi si
considera che (a parte le latenze di rete) il sistema dovrebbe reagire con
un "errore" possibilmente inferiore al decimo di secondo mi sono convinto
che usare un sistema ad RMI sia più "maschio e diretto"   ^_____^
Il mio sistema è così strutturato:
Con il normale comando "java" lancio una serie di classi che si creano un
JNDI ( LocateRegistry.createRegistry(1099) ); queste classi remotizzabili
(le aste) si iscrivono a questo Context, quindi iniziano dei conteggi
particolari (tread che si "muovono" temporizzati...) attendendo che qualcuno
si connetta ad esse.
Ricordo che il comando -java- è correlato da
***-Djava.security.policy=C:\t\webapps\TESI\java.policy*** nel quale c'è un
bel ---grant{permission java.security.AllPermission;}----  tanto per
tagliare la testa al toro...
Quindi attivo un applet che trova il JNDI (
LocateRegistry.grtRegistry(1099) ), trova le aste (skeleton) e quì inizia un
"dialogo" bilaterale con esse ecc. ecc.
Ora rifaccio l'esperimento lanciando Tomcat con il comando
aggiunto -security (che dovrebbe attivare il security manager
catalina.policy... al quale ho aggiunto il solito AllPermission nella
corrispondente sessione "grant").
SE LO STESSO APPLET, viene invocato da una Servlet attivata da Tomcat,
arriva sistematicamente un bel: java.net.SocketPermission ad impedire
all'applet di accedere al Registry.
Sapendo che lavoro su WinXP (e che su di esso DeployTool "funziona" tra il
*no* ed il *ma*...) chi mi svela l'arcano ? (vincendo *almeno* una
pizza...).


La sicurezza che imposti con Tomcat non c'entra un fico se poi l'applet contatta
direttamente il server: l'applet puoi posarlo anche su un web server, e' poi l'applet che
via RMIP contatta il server RMI. 
Se tomcat quindi si limita a "servire" una pagina HTML (sia essa generata dinamicamente o
statica) che referenzia l'applet, la responsabilita' di Tomcat in questo caso e' pari a
quella di un web server (zero, quindi) percio', se e' cosi, puoi lasciar perdere questa
strada.
L'applet, quando e' scaricato, gira all'interno della VM del browser (che puo' essere sia
una VM Microsoft che il Java Plugin, ma credo la seconda che ho detto :-D) e qui entrano
in gioco le restrizioni di security che hanno gli applet (vedi tutorial); in particolare
un applet non puo' contattare un host diverso da quello dal quale e' stato scaricato. 
Se anche solo il *nome* dell'host su cui si trova il registry (e gli oggetti remoti)
cambia rispetto a quello che usi per invocare l'applet, allora non funzionera' un tubo.
Verifica e facci sapere.


 cambia rispetto a quello che usi per invocare l'applet, allora non
funzionera' un tubo.
Che sia Tomcat che, una volta "interessato dalle operazioni", cambi il nome
del mio PC ?!?
Mi puoi dare qualeche delucidazione in merito e/o qualche sito che parla di
questa "nomea dei server" ?
FORSE lascio il caffè e torno alla frutta... anzi, vado a farmi l'ennesimo
caffè e poi controllo meglio questa cosa del nome del Server !!! 8#


No :-)



Hai già "vinto" un pizza   ^___^

Se vuoi che possa risponderti devi fare le cose un po' + semplici.
Fai le prove che ti ho detto al post precedente, poi riparliamo.


...

Mi permetto di intromettermi,
hai provato ad avviare tomcat con -Djava.policy=POLICY_FILE_PATH switch?
Ciao
Mr.Deckard

 Mr.Deckard
L'opzione -Djava.policy non è prevista per lo startup di Tomcat 4.1.24.
E' prevista l'opzione -security che automaticamente usa il file
catalina.policy come file di policy per la sicurezza... ho modificato questo
file aggiungendo, nella sessione *grant*, vari permessi quali:
permission  org.apache.naming.JndiPermission  "jndi://localhost/*";
permission  org.apache.naming.JndiPermission  "*";
permission java.util.PropertyPermission "file.encoding", "read";
permission java.net.SocketPermission "*:1024-", "listen, accept, connect,
resolve";
permission java.security.AllPermission;
ma senza alcun "successo".
Questi sono anche i permessi con cui avvio la mia applicazione, in
particolare la JVM esterna a Tomcat che crea il Registry ed iscrive le
classi da "contattare".
Molte grazie per l'interesse...

> Fai le prove che ti ho detto al post precedente, poi riparliamo.
Fatte:
VAAAAAAAAAAAAAAAAAAAAAAA!!!!!!!!!!!!!!!!
Sono contento "marcio"... ed anche un po' stordito dal fatto meraviglioso...
e dall'ora ^_^
Fondamentalmente l'indirizzo dell'host "cambiava" in quanto le pagine html
si riferivano ad esso una volta col suo "vero" indirizzo-IP, un'altra con
l'indirizzo della porta di loop-back; l'ho "scoperto" mentre seguivo le
prove consigliatemi da Bruno.
Devo lavorarci sů un altro po' perchč c'č ancora qualcosa che non mi č
chiara in questa sequenza di nomi ed indirizzi di host ecc. ecc.
Se e quando riuscirň a racapezzarmici un po' meglio appenderň un post un
pochino piů esauriente di questo (giusto per aumentare il bagaglio di
"conoscenza" globale del news-group...).
Bruno, ti contatterň via e-mail per la pizza omaggio !     :-)

>L'opzione -Djava.policy non č prevista per lo startup di Tomcat 4.1.24.
Scusa la mia umile intromissione (non nconosco bene RMI quindi non
posso parlare dell'argomento), ma volevo farti un appunto sulla tua
ultima affaremazione riguardo a Tomcat.
tutte le opzioni "-D" sono opzioni "accettate" da Tomcat e rigirate
direttamente al sistema. -D, infatti, č il modo per passare delle
informazioni dalla linea di comando alla Virtual Machine che le
inserisce nelle proprietą di sistema. (quindi ci accedi poi con
System.getProperty()).
Se vuoi fornire opzioni addizionali a Tomcat devi usare la variabile
CATALINA_OPTS, mentre se vuoi passare opzioni addizionali alla Java
Virtual Machine devi usare JAVA_OPTS.
	Scusa l'intromissione
	Regards,
		Kazuma
---
I've got nothing against God. It's his fan club I can't stand.
Alex "Kazuma" Garbagnati, 
http://www.kazuma.net
EJB & Tomcat jGuru FAQ Manager, 
http://www.jGuru.com
Tutor "Progetto Scuole", 
http://www.JIA.it
Java Italian Association - SUN - MIUR


Don't mind, a pizze sto a posto :-), magari una birra.


 Virtual Machine devi usare JAVA_OPTS.
Giusto; quando ho letto il post di Deckard avevo ancora in "testa" l'idea
che fossero le proprietà di sicurezza di Tomcat ad impedire l'accesso all'
RMI, invece era un discorso di nomi-host e, fondamentalmente, path... così
ho controllato le opzioni per il lancio di Tomcat ed i comandi necessari ai
file/permessi per la sicurezza mentre mi si consigliava di "fissare" un path
ben definito per entrambe le JVM e l' RMI-Registry.
Grazie della precisazione, Kazuma.
[Sfogo ON]
Devo però dire che, personalmente, nel lavorare col Java mi sono trovato
spesso "bloccato" per problemi di Path... ciò è decisamente seccante,
impiego mediamente un giorno a progettare e scrivere classi ed una settimana
a dire alla JVM dove stanno i  .class !!!
[Sfogo OFF]


Il problema sta nel fatto che si usano i file. In un mondo perfetto (o in un ambiente
perfetto) i file .java, ovvere le unita di compilazione, semplicemente non esistono, ma
esistono solo classi, packages, componenti.
<RANT>
Un IDE che, ad esempio, usa quest'approccio e' Visual Age for Java. Che fine ha fatto?
Smantellato. Sostuitito da Eclipse che, bellissimo per carita', ritorna sull'uso dei file.
Bah!
</RANT>
Ciao,
    Bruno
