RMI:ClassNotFoundException:HelloServer_Stub
arrehman
I am writing a my first RMI program. But I am stuck with a
ClassNotFoundException. Tried again and again a thousand times only to
get disappointed. This is a very basic HelloWorld program that copied
from an online tutorial. RMI folks, out there, please try to help me.
RMI server program is running fine and the remote object is bound to
the registry. but heres the exception that I am getting when i try to
run the RMI client.
HelloServer exception: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: RMI.Server.HelloServer_Stub
java.rmi.UnmarshalException: error unmarshalling return; nested
exception is:
java.lang.ClassNotFoundException: RMI.Server.HelloServer_Stub
java.lang.ClassNotFoundException: RMI.Server.HelloServer_Stub
at java.io.ObjectInputStream.inputObject(Compiled Code)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:232)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:89)
at RMI.Client.HelloClient.main(HelloClient.java:12)
I know that this HelloServer_Stub is not getting downloaded to the
client machine for some reason. If I copy them to the client machine
manually the RMI client runs fine. I tried my best here. The CLASSPATH
in the server does not point to the HelloServer_Stub class. I have
specified the java.rmi.server.codebase appropriately. Donno what is
going on. What would I be missing here? Any clues? help me.
FYI:these are the classes I used, RMI.Hello.Hello.class declaring the
remote interface, RMI.Server.HelloServer implenting the remote interface
and RMI.Client.HelloClient trying to contact the RMI.Server.HelloServer
class running in another machine.
thanks
arrehman
Sent via Deja.com http://www.deja.com/
Before you buy.
Zotto
the Skel class I guess) back to the client everything works fine. As
far as I know that is what you MUST do with RMI. There is no
"automatic" return of the Stub or Skel classes back to the client. You
must copy them there. At least that is my understanding.
Zotto
In article <881sis$qi6$1...@nnrp1.deja.com>,
arrehman
yes it works fine when i copy the stub files to the client manually.
thats very inefficient way of doing RMI. and thats not the way RMI
supposed to work. the client is supposed to download the stub files from
the server dynamically. it does that using http or ftp protocol. man!
whatever i do the the client fails to do just that. it gives me this
stub not found exception on Naming.lookup. i tried avoid using the
packages i used in the prev posting. no luck. gives me the same error.
been on this for 2 days! tried to be very cautious my best. but i know
there is a way!(cause i remember i have made worked the
ComputeEngine-ComputePi RMI sample given in the sun.com java tutorial
successfully around a month or two ago) i forgot i did that. i know this
works. but something...something is there...
i know many guys faced this error as i searched various forums for the
solution. the solution is make sure that java.rmi.server.codebase
property is set properly and that the classpath doesnt point to the stub
classes before the registry is started. i made sure these things but
still.....
what else could i be doing wrong, guys.................????
regards,
arrehman
In article <881uv0$sda$1...@nnrp1.deja.com>,
Lauri Pesonen
> Hi,
> yes it works fine when i copy the stub files to the client manually.
> thats very inefficient way of doing RMI. and thats not the way RMI
> supposed to work. the client is supposed to download the stub files from
> the server dynamically. it does that using http or ftp protocol.
No, that's not right. RMI does not move class files from the server to
client or anywhere else. The Registry just passes an instance of the
stub class to the client over the network and then the client uses
this instance to make remote method calls to the server. The client
needs to have the class representation (i.e. class file) of the
instance in order to be able to de-serialize the
instance. Unfortunately RMI does not support transferring class files
with the Stub. Other RMI implementations or architectures based on RMI
have implemented class file transfers to the architecture, so that you
do not have to copy the Stub class to the client manually.
HTTP and RMI go together when the HTTP port is used to pass RMI calls
through firewalls, but I don't think that thas anything else to do
with the actual HTTP protocol.
How is it more inefficient to copy the stub with the client to the
host where it's used than copying with the Stub instantiation?
> man!
> whatever i do the the client fails to do just that. it gives me this
> stub not found exception on Naming.lookup. i tried avoid using the
> packages i used in the prev posting. no luck. gives me the same error.
> been on this for 2 days! tried to be very cautious my best. but i know
> there is a way!(cause i remember i have made worked the
> ComputeEngine-ComputePi RMI sample given in the sun.com java tutorial
> successfully around a month or two ago) i forgot i did that. i know this
> works. but something...something is there...
Your sure you didn't have the Stub class in your CLASSPATH
accidentally? A very common mistake...
> i know many guys faced this error as i searched various forums for the
> solution. the solution is make sure that java.rmi.server.codebase
> property is set properly and that the classpath doesnt point to the stub
> classes before the registry is started. i made sure these things but
> still.....
Never the less I could be totally wrong here and Sun has implemented
the Stub transferring to the JDK1.2 RMI...
--
! Lauri
<--------Lauri-Pesonen------------------------------------------------->
'Knock me down I'll just come back running'
<-----------------------------TiK Lukkali'2k--------------Finland------>
Joseph Dane
Lauri> arrehman <arre...@my-deja.com> writes:
>> Hi, yes it works fine when i copy the stub files to the client
>> manually. thats very inefficient way of doing RMI. and thats
>> not the way RMI supposed to work. the client is supposed to
>> download the stub files from the server dynamically. it does
>> that using http or ftp protocol.
Lauri> No, that's not right. RMI does not move class files from
Lauri> the server to client or anywhere else. The Registry just
This, and everything else in this post, is wrong. Stub class files do
*not* need to be available on the client for RMI to work. The remote
interfaces do have to be available, naturally, but not the stubs.
Make sure that you (the orginal poster) are setting an
RMISecurityManager in the client. Without this, stub downloading
can't happen, and you can only access local (CLASSPATH) stubs. You
can also check the log files of the web server to see if it is having
problems accessing the stubs. Finally, be sure that the "codebase"
property ends with a "/" character, e.g., http://foo.com/java/stubs/.
--
joe
Lauri Pesonen
I stand corrected. I haven't played with Java's RMI in a while, so I'm
not up to speed with all the features. Should've checked before
posting ;)
Zotto
arrehman
>
> Ditto!! Thanks, this thread has been helpful!!
>
> Zotto
>
and i realize the stub files are being downloaded successfully!!!! but
on the client side it doesnt recognize and realize that?
now i am wondering if its got any thing to do with the JDK versions. my
server and client machines run different JDK versions.
arrehman
Joseph Dane
arrehman> hmm. i couldnt still make it work though. i checked the
There's only a few more things I can think of.
* Make sure that when you start the registry, the stub class files
are *not* in the CLASSPATH of the registry. In fact, I usually
arrange for the registry to start in a process with an empty
CLASSPATH.
* Have you checked the java console on the client side? Maybe a
security exception is being thrown. In this case, you'd have to
make sure a policy file exists on the client allowing connection to
the registry and server machines.
Good luck.
--
joe
arrehman
yes i did made sure the classpath in the server is empty before i start
the registry. i used the same policy file on bother server and client.
yes i did. i tried with and without jar files for the remote interface.
here are the basic things i followed to run the rmi programs:
classes involved:
Hello.class:declares the sayHello interface
HelloWorldServer.class:implements the remote interface Hello
HelloWorldServer_Stub.class and HelloWorldServer_Skel.class:results
after passing HelloWorldServer.class thru rmic
HelloWorldClient.class:the rmi client
steps done : writing out of my mind since i have done it lotta times :)
1. i created a virtual directory called Hello in my web server (say
PLUTO) and copied Hello.class, HelloWorldServer*.class files
2.i have unset the classpath
3.i started the rmiregistry
4.i set the classpath to point to the Hello virtual directory
5.then i started the rmi server using the following command
java -Djava.rmi.server.codebase=http://pluto/hello/
-Djava.rmi.server.hostname=pluto -Djava.security.policy=java.policy
HelloWorldServer
(note:later i tried using IP address instread of the name PLUTO)
where java.policy is a text file in Hello directory containing:
grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,accept";
permission java.net.SocketPermission "*:80", "connect";
};
6.I see the message 'HelloServer is bound the registry' and I am very
happy.
7.Now back to the client machine
8.Where I have directory called HelloClient, with Hello.class,
HelloWorldClient.class and java.policy file, same as in the server
9.I issue the following command:
java -Djava.rmi.server.codebase=http://pluto/hello/
-Djava.security.policy=java.policy HelloWorldClient
10.I get this error making me scratch my head over and over ...
HelloWorldClient Exception: error unmarshalling return; nested exception
is:
java.lang.ClassNotFoundException: HelloWorldServer_Stub
java.rmi.UnmarshalException: error unmarshalling return; nested
exception is:
java.lang.ClassNotFoundException: HelloWorldServer_Stub
java.lang.ClassNotFoundException: HelloWorldServer_Stub
at java.io.ObjectInputStream.inputObject(Compiled Code)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:232)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:89)
at HelloWorldClient.main(HelloWorldClient.java:9)
are you with me??
i checked the server web log and found that the stub files are
downloaded successfully. i tried various ways. making the client a
virtual directory and poiting the codebase to that directory when i try
to run the client...etc.
well, then i know that the JDKs in both server and client are diff
versions. donno if thats the problem. got tired of it and stopped trying
any more. i would try that in few days..........
could you think of anything that i missed???????
thanks a million!!!!!!!!!
regards,
Joseph Dane
Well, I'm stumped. One thing you should keep in mind: the records in
the web server log files are *not* there because the client has
downloaded the stubs. Assuming you are running on some sort of UNIX
platform, you can use "tail -f LOGFILE" to watch the log entries as
they are written to the file. You will see that the stubs get
downloaded when you start the *server*, not the client.
What happens (I think: I'm more than a little fuzzy on the details
here) is that the server registers with the registry, and the
*registry* then loads the stubs from the web server. So, the fact
that you see entries in the log file indicating that the stubs are
being accessed does not mean that they ever make it to the client.
The only other thing I can think of is that there's some basic network
connectivity problem between the client and the registry machine. As
I said above, the fact that the stubs are being accessed from the web
server doesn't mean that the client ever sees them.
--
joe
arrehman
again. The stub files are being downloaded by the server not the
client. Makes sense. So the stubs are not at all downloaded by the
client. And thats the problem I face.
In article <wo4sb8i...@menpachi.swfc2.nmfs.gov>,
wja...@hotmail.com
I've had a similar problem, and explicitly granting my client
application filesystem access rights in .java.policy fixed it.
Good luck!
Jarek
In article <88h217$5tq$1...@nnrp1.deja.com>,
cit...@my-deja.com
You've almost certainly forgotten to install a security manager.
Without it, the security file is never read. Try adding, just before
the Naming.lookup() command:
System.setSecurityManager(new RMISecurityManager());
Best,
-- Bob
In article <88eqqf$l7q$1...@nnrp1.deja.com>,