Todd O'Bryan <email@hidden> writes:
> The weird thing is that ServerImplementation_Stub.class is right
> there inside the same folder as StartServer.class and
> ServerImplementation.class, so I can't understand why the ClassLoader
> can find them and not it. I have this problem both when I run from
> inside Eclipse using the RMI Plugin, but also when I run from the
> command line.
>
> Any ideas?
are you using a pre-1.5? things have changed in 1.5 in ways that I'm
not completely familiar with (you don't need to run a separate stub
compiler, for one thing), but I might still be able to help.
there are two JVMs involved here: your server and the RMI registry,
into which you're trying to bind a reference to your server. it's the
registry that's complaining about not being able to load the class.
probably when you started the registry you didn't set its CLASSPATH to
something containing the stubs. which is normally exactly what you'd
want to do.
much more about this can be found here:
http://java.sun.com/j2se/1.5.0/docs/guide/rmi/codebase.html
one of the features of RMI I didn't mention previously was "code
downloading". RMI can arrange for java classes to be downloaded
from somewhere to the client prior to being executed. typically you'd
do this with the stubs. that is, rather than packaging the stub
classes with the client, you'd allow the client (the RMI runtime on
the client) to download the classes at runtime.
one of the requirements for stub downloading to work is that when you
start the registry it *must not* be able to load the stubs itself
through its own classpath. so you might start it with an empty
classpath, say. then when your server is binding a reference into the
registry, you set a system property on the server
("java.rmi.server.codebase"), and this property is use to annotate the
serialized stub instance. when the stub shows up at the registry, the
registry will first try to load the stub class from its own classpath,
and failing that will check for the codebase annotation. if it finds
one, it'll make a connection to that URL to download the stub class.
this is all very cool, but in my experience is often more hassle than
it's worth. for one thing, you need to setup a webserver somewhere
(or a shared filesystem) to which to point your codebase, and you need
to make sure the stubs get copied there.
in some situations, this would probably be worth it. as I said,
though, I usually avoided it.
the easiest way to avoid code downloading is to just make a single jar
file, containing the servers and the stubs, and arrange for that
jar to be in the registry's classpath *and* the client's classpath.
this effectively disables code downloading. if you wanted to, of
course, you could have two jars: one containing the server
implementation (which never has to leave the server) and another
containing the stubs and any parameter implementation classes needed
on the client, and just distribute that second jar.
again, all this is true for <1.5, and probably mostly true for 1.5,
but YMMV.
--
joe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
