You are returning a class that is not on the client.
You have two choices.
1) Put the class in the client's classpath
2) Configure an RMISecurityManager to download the
class from the server.
The problem is that I'm returning an interface not an implementation. The interface is known to the client while the implementation isn´t. The interesting part is that if I include the implementation class with in the jar of the bean it works (while never using it directly in code). Do you have any other ideas? Why would the bean need access to the implementation class? Doesn't RMI cast the deserialized object to the type of the interface directly without the implementing class on the classpath?
Don't get confused between what the compiler sees
and what the VM sees.
At compile time (and for casting) you are using the
But it is the implementation's that is
executed, you need the byte code from the class.
Of course if this was a remote object the implementation
wouldn't be passed to the client, only the proxy or stub.
Adrian, thanks for helping. The problem is still not solved. My idea of the RMI is something like the following.
Serializing an object will save the non-transient variables of the instance and send it to the destination host as bytestream. As you said, the implementation will not be present and the JVM will try to load the implementation from somewhere. I belive there is a server at jboss that the classloaders connect to to download the class files or are there any other way for the RMI to provide the implementation transparantly. With transparantly I mean not putting the implemenation class in the jar nor in the jboss classpath. (By the way, the interface is public and the implementing class is package private).
To download classes from the server you need to
configure an RMISecurityManager in the client.
Have a look at the javadocs for that class
or the RMI manual.