Re: Dynamic Class Loading & AbstractMethodError

Miguel Correia Ricardo wrote:
> Hello again!
>
> I've decided to follow the advices of the article "The Lifecycle of an
> RMI Server", and change somethings in setup of my applications.

Hi Miguel, it sounds like you've got it working, great.  Without seeing the
exact logging, it's harder to specifically answer your questions.  However, the
last issue you mentioned is that TaskMessage has to be in the codebase of the
server.  This is a requirement because it is the implementation of the Task
interface, and it is that classes definition that is returned by
MyServiceInterface.getTask().  So, it must be a part of the codebase that the
client can download from, or there is no way that the client.

This is an important part of Java's distributed computing model through the RMI
architecture (You may want to look at Jini for ever more tools).  The mobile
code returned by the getTask() call allows you, the service deployer, to control
how the client interacts with your service.  Currently, your MessageTask is a
serializable object.  But, you could change it to be a remotely accessed RMI
object.  Asside from the "throws RemoteException" addition to the API calls of
Task(), the client would not need to know whether it was dealing with a remote
Object or a local object.

The getTask() method call goes out through the remote implementation of the
MyServerInterface.  The MyServiceInterfaceImpl class is running on your server,
and the *_Stub.class file is what your client downloads to access that
server/service.

Arguments to remote method calls must be defined in the codebase of the caller,
or in the classpath of the called, remote service (interfaces almost always are
distributed everywhere with implementations visible in codebases).  Return
values are the same way.  Any object returned must be composed of, and reference
  only, classes defined by the calling party, or they must be visible in the
codebase of the called server/service to be downloaded.

With fewer words, any object that flows from one VM, to another, must either be
defined in the codebase of the source VM, or resolvable by the classpath of the
receiving VM.  There is no magic here, the class definition has to be available
somehow.

Gregg Wonderly

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html