shyamala
asked on
RMI callbacks
We are using RMI to call a remote application's methods from an applet. We know that the reverse (ie. calling an applet's method from an application ) is also possible but we are not able to do it. Can u give us a step by step method with all the details (directory - name of server etc. ) and also suggest why it is not currently possible)
applet must extend a remote interface, should be signed, register with the rmi registry with naming.bind, should not create rmi security manager. all the classes (stubs and skeletons) must be accessible to both application and applet (classpath and code base).
RmiRegistry is an .exe Application.
It could be run in the Client, but it's not a good solution.
And, It's not a good idea to open ServerSocket on Applet.
It could be run in the Client, but it's not a good solution.
And, It's not a good idea to open ServerSocket on Applet.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Mr. Knolloc, Thanx for ur interest. I tried out your solution but I am getting Applet security exception. Can u give a more detailed answer, with the exact folder names in which the program resides (it is ok if it is hard coded) and all the other details
Sure. According to netscape, you will get an applet security exception if the proxy/stub is found in the local machine's classpath. You may have received an exception saying that you can not connect to <remote ip address> from <local class path>. The reason is that the class loader in netscape found the proxy on your local machine, and the proxy is trying to connect to the web server. Well, the proxy can only connect to the machine it was downloaded from (in this case, local), so you will get a security exception when you attepmpt the callback. I also had this problem, but because of other activities I coudln't complete my tests. I recommend you make sure all traces of the stub_ skel_ classes are removed from the local system and have them ONLY reside on the web server. Then try the test.
Also, you only need rmiRegistry running on the web server (if that is where your server object is running, which, in the case of an applet call back, is required because the applet will only be able to connect to objects on the web server it was downloaed from). I'll crack open the books and try to get my demo working and send you anything I am able to come up with.
-Chris
Also, you only need rmiRegistry running on the web server (if that is where your server object is running, which, in the case of an applet call back, is required because the applet will only be able to connect to objects on the web server it was downloaed from). I'll crack open the books and try to get my demo working and send you anything I am able to come up with.
-Chris
Here's some specifics and an example:
remote_Applet.class : interface to the applet
mainApplet.class : the applet that implements the remote_Applet interface.
remote_Server.class : interface to the server class
mainServer.class : the server object that implements the remote_Server interface
mainApplet_stub/skel : the proxy/stubs generated by calling rmic on mainApplet.class
mainServer_stub/skel: the proxy/stubs generated by calling rmic on the mainServer.class
Here's where the files should go:
remote_Applet.class : in web server applet directory AND in classpath of server object (the server object needs it to make callbacks.)
mainApplet.class : in weber server applet directory
remote_Server.class : in web server applet directory AND in classpath of server object (the applet needs it to connect to the remote object)
mainServer.class : in the server classpath
mainServer_stub/skel : in web server applet directory AND in classpath of server object
mainApplet_stub/skel: in web server applet directory AND classpath of server object
Notice how both the applet and server objects need to have all the stub/skel classes in their classpaths. this is because the stub/skel is doing the work of making the connection to each other and 'marshalling' the data being transfered from client to server. if there was no callbacks being performed, only the server would need the skel and client need the stub in their classpaths.
I hope this helps a little bit. I'll dig up some of my old work and try out some things and let you know if I get it to work!
-Chris
remote_Applet.class : interface to the applet
mainApplet.class : the applet that implements the remote_Applet interface.
remote_Server.class : interface to the server class
mainServer.class : the server object that implements the remote_Server interface
mainApplet_stub/skel : the proxy/stubs generated by calling rmic on mainApplet.class
mainServer_stub/skel: the proxy/stubs generated by calling rmic on the mainServer.class
Here's where the files should go:
remote_Applet.class : in web server applet directory AND in classpath of server object (the server object needs it to make callbacks.)
mainApplet.class : in weber server applet directory
remote_Server.class : in web server applet directory AND in classpath of server object (the applet needs it to connect to the remote object)
mainServer.class : in the server classpath
mainServer_stub/skel : in web server applet directory AND in classpath of server object
mainApplet_stub/skel: in web server applet directory AND classpath of server object
Notice how both the applet and server objects need to have all the stub/skel classes in their classpaths. this is because the stub/skel is doing the work of making the connection to each other and 'marshalling' the data being transfered from client to server. if there was no callbacks being performed, only the server would need the skel and client need the stub in their classpaths.
I hope this helps a little bit. I'll dig up some of my old work and try out some things and let you know if I get it to work!
-Chris