loading RMI class (Stub's) for client using cobebase

[Diego Bowen]

I'm having problems loading remote classes, namely the client load the stub class from the server.
On the Server side
My command line looks like this:
java -Djava.rmi.server.codebase://localhost/~DBowen/myRMI
-Djava.security.policy=java.policy HelloImpl &
[1] 5739
DBowen@linux:~/public_html/myRMI> HelloImpl err: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.net.MalformedURLException: no protocol: //localhost/~DBowen/myRMI
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.net.MalformedURLException: no protocol: //localhost/~DBowen/myRMI
However if I do the following instead:
My command line input:
java -Djava.rmi.server.codebase://192.0.3.17/~DBowen/myRMI -Djava.security.policy=java.policy HelloImpl &
[6] 5964
DBowen@linux:~/public_html/myRMI> HelloServer bound in registry

One the Client side:
my command line imput:
java -Djava.rmi.server.codebase://192.0.3.17/~DBowen/myRMI -Djava.security.policy=java.policy HelloMain
HelloApplet exception:~DBowen/myRMI/HelloServer
java.rmi.NotBoundException: ~DBowen/myRMI/HelloServer
.......
As I currently understand java rmi, the whole point is for a remote client to load a stub class where upon it uses it to invocate allowed methods (as defined by the class). Can someone help me with this Please...there is not much out there...Thanks in advance...D

[Vinod John]

Originally posted by Diego Bowen:
java -Djava.rmi.server.codebase://localhost/~DBowen/myRMI
-Djava.security.policy=java.policy HelloImpl &

Should this not be
-Djava.rmi.server.codebase=http://localhost/~DBowen/myRMI
or
-Djava.rmi.server.codebase=file://path

[Diego Bowen]

Thanks for that and I got the server up and running however i'm still getting the following exception on the remote client:
ON THE REMOTE CLIENT
cmd line input:
java -Djava.rmi.server.codebase=http://(serversIPaddress)/~DBowen/myRMI/
-Djava.security.policy=java.policy HelloMain
HelloApplet exception:~DBowen/myRMI/HelloServer
java.rmi.NotBoundException: ~DBowen/myRmi/HelloServer
............
From my understanding thus far the whole purpose of specifing the codebase path is so that the "Stubs" on the server can be founded and loaded. Thanks in Advance..D

[Diego Bowen]

Regarding this same topic. Is it the case that once the remote method is executed it is load in the working directory??? I would think it to be the case, but since I have yet to see this work properly I'm not absolutely sure. Thanks D

[Dana Hanna]

From my experience, the codebase has to be the remote classes stored in a jar file, hosted on a webserver. We tried to use the codebase to specify a windows share: \\computer\\share\somejar.jar. Didn't work...

[Radha MahaLakshmi]

Hi
Like applets, the classes needed to execute remote method calls can be downloaded from "file:///" URLs, but like applets, a "file:///" URL generally requires that the client and the server reside on the same physical host, unless the file system referred to by the URL is made available using some other protocol, such as NFS.
As the RMI server and client can not reside on the same machine
the classes needed to execute remote method calls should be made accessible from a network resource, such as an HTTP or FTP server.
so we need to specify some thing like below.
If the location of your downloadable classes is on an HTTP server named "rmiserver", in the directory "rmiclasses" (under the web root), your codebase property setting might look like this:
-Djava.rmi.server.codebase=http://rmiserver/rmiclasses/
Hope this helps.
I am also working on rmi,started few days ago.
I dont understand why do we need to use dynamic class loading.
we need copy (made avilable through classpath in clients machine)the remote interface.So while giving the remote interface we can provide the stbu class also in the same jar to clients machine.right???
Can anyone help me???
Regards
Radha

[John Hollingsworth]

Originally posted by Radha MahaLakshmi:
Hi
/snip/
I am also working on rmi,started few days ago.
I dont understand why do we need to use dynamic class loading.
we need copy (made avilable through classpath in clients machine)the remote interface.So while giving the remote interface we can provide the stbu class also in the same jar to clients machine.right???
Can anyone help me???
Regards
Radha

Well, RMI gives me headaches but I thought the whole point of RMI is to give a complete level of abstraction between the requesting client and the replying server. Copying the remote interface would violate that precept as I understand it.
[ August 29, 2003: Message edited by: John Hollingsworth ]
[ August 29, 2003: Message edited by: John Hollingsworth ]

[Radha MahaLakshmi]

Hi
I accept that.
Let us assume that i am develping a RMI based application.My client is HelloClient.java reside in client machine.Remote interface and implementation class resides in server.
When i compile the HelloClient.java in client machine,if i dont have the remote class(Hello.class) in client machine its giving a compilation error.
So i had to have the Hello.class in client machine to succed in compilation.
Here i wanted to know is there any other way where with out having the remote class i can succed in compilation???
If we had to have the remote class in client machine at the time of compilation why can't we copy the stub class also and run the application.

Regards
Radha

[John Hollingsworth]

Originally posted by Radha MahaLakshmi:

/snip

When i compile the HelloClient.java in client machine,if i dont have the remote class(Hello.class) in client machine its giving a compilation error.
So i had to have the Hello.class in client machine to succed in compilation.
Here i wanted to know is there any other way where with out having the remote class i can succed in compilation???

If you're following the naming conventions for RMI, Hello.class is an interface. This isn't downloaded via RMI. I agree with you this is questionable, but this is how it is constructed. I myself think this is poor design. That interface should come down to the client without previous deployment.
[ September 02, 2003: Message edited by: John Hollingsworth ]