I am getting an error whilst attempting to use the UnicastRemoteObject.export() method. But when I change my class to extend UnicastRemoteObject I do not get an error. The error I get is below. Any ideas how I can get around this?
I am using Java 6 and running the code from within Eclipse. When I package the code up in a JAR and run from the command line I do not get the error. So I am specifically trying to get this working within a project in Eclipse. I've provided code example below which display the problem - all you need to do is create an empty Java project in Eclipse and copy all the code into one class file named Server, and then run it.
This is the error that I get:
Exception in thread "main" java.rmi.StubNotFoundException: Stub class not found: ClockImpl_Stub; nested exception is:
Below is the code example that produces the error:
Below is the code example that does not produce an error - it runs fine.
Even when I run the example that is using UnicastRemoteObject.export() from the command line it does work - it throws the same exception that it cannot find the ClockImpl_Stub class.
All I am doing to run the class from the command line is javac Server.
When I run the JAR that contains the class from the command line I am using java -jar rmi.jar and it works. (I have Main-Class in my MANIFEST.MF pointing at the Server class).
My understanding is that if you don't specify a classpath to java.exe then only the current directory will be on the classpath. Based on this, both set-ups have the same classpath, yet in the JAR version java.exe finds the Stub class.
I've no idea how the Stub generation works i.e. where it puts the generated class file. But it would seem that it is putting it in different locations for both of my set-ups? Confused
The code runs from both the command line and Eclipse.
However, this still leaves me puzzled as to why using UnicastRemoteObject.exportObject(clock) worked when I ran the class from within a JAR file, but it didn't work when I simply ran the class from the command line. Any ideas?
Scroll down to the method we used on line 18 of the ServerImplementor which is the exportObject(Remote obj). Now see the return type of the method? RemoteStub! Houston we have a problem…! Here is where all the fuss is created. Now notice the method just below that, exportObject(Remote obj, int port). This returns a pure Remote object.
I had similar problem, and after changing from exportObject(Remote obj) to exportObject(Remote obj, port) now everything works fine. I thought this could help you, but sorrry I didn't realize what you exactly want.