Question

The following method:

    private void startServer() { // snippet that starts the server on the local machine
        try {
             RemoteMethodImpl impl = new RemoteMethodImpl();
             Naming.rebind( "Illusive-Server" , impl );
        } catch(Exception exc) {
            JOptionPane.showMessageDialog(this, "Problem starting the server", "Error", JOptionPane.ERROR_MESSAGE);
            System.out.println(exc);
        }
    }

throws this exception:

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
        java.lang.ClassNotFoundException: Interfaces.RemoteMethodIntf

When i start my project, i am greeted with the message in JOptionPane saying problem starting the server and then the above exception. What could be the reason for this?

I don’t understand why does the last statement of exception says class not found exc when i have imported the right packages.

Answer 1

There are four cases of this exception.

1. When exporting: you didn’t run ‘rmic’ and you didn’t take the steps described in the preamble to the Javadoc for UnicastRemoteObject to make it unnecessary.

2. When binding: the Registry doesn’t have the stub or the remote interface or something they depend on on its classpath.

3. when looking up: the client does’t have these things on its classpath.

4. When calling a remote method: you either sent something to the server of a class not present on its CLASSPATH, or received something from the server (including an exception) of a class not on your CLASSPATH: in both cases possibly a derived class or interface implementation of a class or interface mentioned in the remote interface’s method signature.

This is case 2. The Registry can’t find the named class.

There are several solutions:

1. Start the Registry with a CLASSPATH that includes the relevant JARs or directories.

2. Start the Registry in your server JVM, via LocateRegistry.createRegistry().

3. Use dynamic stubs, as described in the preamble to the Javadoc of UnicastRemoteObject. However you may then still run into the same problem with the remote interface itself or a class that it depends on, in which case 1-3 above still apply to that class/those classes.

4. Ensure that case (4) above doesn’t occur.

5. Use the codebase feature. This is really a deployment option and IMO something to be avoided at the initial development stage.