Newsgroup: it.comp.java
Titolo: Mannaggia a chi ha inventato l'RMI!

Salve a tutti,
faccio seguito al discorso iniziato con "RMI e gli Applets"-
dopo diversi giorni di tentativi sono venuto a capo che l'unico
modi di lanciare un Applet che va a collegarsi con il Server RMI
(assegnato allo STESSO host) per eseguire chiamate remote è
quello di firmare l'applet, ovvero utilizzare il Plug-in.
Se lancio l'applet da Netscape, nella console ottengo come già detto
netscape.security.AppletSecurityException: security.Couldn't connect to
'myhost' with origin from ''.
Tutto questo perchè l'host di origine è file\:c:\rmi\start.html
ovvero dove risiede fisicamente la pagina contenente l'applet.
Ovviamente il Classloader s'imbestialisce perchè provo ad uscire
dall'host di origine, cosa impossibile anche se siamo quasi a Pasqua.
Allora che ti faccio: trattengo ancora un po' le maledizioni e metto la
beneamata
pagina su un server HTTP montato sulla macchina...e invoco l'applet da http
anzichè
cliccarci su...
Esito:
Aggiro la sicurezza ma ottengo una serie di errori coreografici
rispettivamente su
Netscape 4.6:
java.lang.NoSuchMethodError: java.rmi.server.RemoteRef: method invoke
(Ljava/rmi/Remote;Ljava/lang/reflect/Method;[Ljava/lang/Object;J)Ljava/lang/
Object; not found   at EmployeeImpl_Stub.getEmpInfo(Compiled Code)   at
EmpApplet.init(Compiled Code) * at
.............................................
IExplorer 5.0 :
java.lang.ClassNotFoundException: java.rmi.Naming
 at com/ms/vm/loader/URLClassLoader.loadClass (URLClassLoader.java)
 at java/lang/ClassLoader.loadClassInternal (ClassLoader.java)
........................................................
Alla fine ho optato per la forza bruta! ho messo in campo il
Plug-in......risultato
l'applet gira! (anche scontato del resto, visto che con appletviewer - che
utilizza  la stessa VM -l'applet mi funzionava dal primo momento )
Ma allora come si fa a far funzionare un applet con la VM di Netscape o IE
????
Impossibile deduco .....ovvero ci sarà sicuramente un modo ma quanti giorni
devo sbatterci la testa per trovarlo ????
dopo qualche giorno di crash-course in RMI mi viene proprio voglia di
gettare tutto alle
ortiche, è eccessivamente difficile, non c'e' compatibilità tra i
browsers.......vi invito
a guardare questo link che ha delle FAQ per RMI in bollettini mensili:
http://archives.java.sun.com/archives/rmi-users.html
C'e' una quantità spaventosa di domande, segno questo che effettivamente è
molto difficile da padroneggiare...allora la domanda nasce spontanea,
facendo un rapporto difficoltà/benefici MA NE VALE LA PENA????
Sempre su javasoft c'e' un documentario molto "profondo" che parla di
Servlets, Serializzazione e RMI. Spiega una cosa molto interessante: ovvero
come fare interagire il client Applet con il relativo Servlet attraverso un
Proxy Object. In questo caso le chiamate RMI vengono eseguite da Servlet. Ci
si può arrivare da 
javasoft.com
 navigando su documentation...nel Frame
sinistro...è insieme ad una serie di articoli tecnici molto interessanti.
Se qualcuno si vuole cimentare su questo articolo insieme a me, sarò ben
lieto di condividere gioie e dolori....fate un fischio sulla mia email o
postate al newsgroup.
Attendo palpitante i vostri commenti
Francesco Marchioni
chec...@libero.it

postate al newsgroup.
L'approccio e' quello usuale: una volta messo in piedi un oggetto remoto, ha 
poco senso non usarlo anche quando - fisicamente - remoto non e', di solito una 
servlet.
Il tunnelling dei risultati su HTTP e' una delle features piu' interessanti: in 
RMI2.0 e' "compresa nel prezzo", ma i browser ancora non la supportano. 
Sfruttando la reflection, non e' difficile automatizzare marshalling e 
unmarshalling dei risultati su HTTP response - che e' poi *esattamente* quello 
che fa RMI, solo appunto embedded in risposte HTTP. Giusto in questi giorni sto 
valutando se realizzare il codice per questo o no per degli oggetti di session 
management che abbiamo realizzato. L'idea e' che se prima o poi i browser 
supporteranno RMI2.0 non serve,  altrimenti e' una cosa utile. 
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 >postate al newsgroup.
Il meccanismo usato è semplice ma poco OO, in quanto bisogna passare dei
parametri alla servlet (è meno profondo di quanto sembra ;)). Con l'uso
delle reflection API si può fare molto di meglio, vedi il mio articolo
su CP di Novembre n.85 per una possibile implementazione e design
relativo. (se non riesci ad ottenerlo te lo posso postare, ma non dirlo
a nessuno)
ciao 
-- 
Ugo
__________________________________________________________________________
"La perfezione si ottiene non quando non c'è nient'altro da aggiungere, 
 bensì quando non c'è più niente da togliere." Antoine de Saint-Exupéry
__________________________________________________________________________
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home Page: 
http://www.ugolandini.net
Mentoring: 
http://www.projectoo.com
Work Phone: 06/5814740
Fax Phone: 06/233207542 
Cell Phone: 0347/6310749 - 0347/4783580
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

a nessuno)
Ti riferisci a me o a Francesco, che faceva la domanda? :)
PS: grazie per le info su togheter





il CORBA, da quanto ho letto, rimarrà 100% Java ?
Concettualmente RMI e CORBA sono identici. Le uniche differenze sono che CORBA 
usa IDL per specificare le interfacce, e RMI usa java; e che CORBA usa IIOP 
come protocollo di interazione, mentre RMI essenzialmente serializza oggetti su 
uno stream di byte. RMI-IIOP, appunto, permette un client java di comunicare 
con un oggetto remoto tramite IIOP invece che sfruttando la serializzazione. 
"Migliora" nel senso che permette di accedere ad oggetti CORBA esistenti da 
java in modo trasparente.
Non e' che pero' il mondo pulluli di sistemi distribuiti e oggetti CORBA gia' 
implementati: quindi il miglioramento e' relativo. :)
