• Post Reply Bookmark Topic Watch Topic
  • New Topic

RMI 002  RSS feed

Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note: Since posting this item, I have found out some of the answers, which
I will offer in italics; of couse, it's always possible that my current understanding
of what the correct answers are is incorrect.

Summary of my question: The first four segments are a simple RMI
client and server in package rmi2. They use the most standard
technique for people first experimenting, where, namely, the ...Impl
class extends UnicastRemoteObject thus:

However, what happens when your ...Impl class does not extend
UnicastRemoteObject? Then you are free to extend some other
class of your chosing.
This whole idea would have worked out alright if and only if
I didn't later place a restiction on my CommonInterface that
it throw MyException; that is, the local object and the
remote object that the client receives would have ended up
as children both extending the same parent abstract class,
and that abstract class would contain the methods that do
most of the work. This plan works if CommonInterface has
methods which throw Exception, but won't work if the methods
throw either MyException for the local subclass and RemoteException
for the remote object methods.

The first step is to show the code, based on Core Java, but
extended by me which is the four classes in package rmi2 which does
things the simplest way people usually start out (i.e., the ...Impl class
extends UnicastRemoteObject). Then I will come to my question.

So, I now define a new package called rmi3. I want to re-define
GenImpl so that it does not extend UnicastRemoteObject.
The reasoning is that it may buy me more flexibility (the analogy
is to a class you want to make runnable, you can extend Thread,
or for more flexibility, implement Runnable instead).
Dutifully referring to my textbook on page 340 on the sidebar,
it says, in effect, that to do what I want to do, I need to manually
instantiate the server objects and pass them to the static
exportObject method (noting that the server class must still
implement a [programmer defined] remote interface).
And, two examples, though
not much context is given:


His use of the "Server Object" is refering to my GenImpl class.
Anyway, although everything works fine, I never have to
invoke UnicastRemoteObject.exportObject(...). Everything
continues to work fine (both to the localhost or over a live
internet connection). Question: why?

Because all the classes were accessable, either in the rmi
directory or in the .jar file; thus, no stubs needed to be
transported across the network. [Note: the fact that no
stubs are being transported across the network is why
a security manager is not required.] If stubs needed to
be transported across the network, then these exportObject(...)
method calls would be imperative.

Here are the classes which significantly change in package rmi3, and they
work even though UnicastRemoteObject.exportObject(...)
is never invoked anywhere.
Here is the most important change, as the following class
extends Object (and in the real world, it would extend some
class of mine instead, but Object should suffice for this test):

The class GenServer is unchanged, as the changes I tried to
for example,
are not necessary, because everything works fine either
1. with the calls in
2. with the calls commented out.

Summary: how is this mystery about UnicastRemoteObject.exportObject(...)
I've retrospectively filled in some of the answers above.
Javini Javono
[ January 25, 2004: Message edited by: Javini Javono ]
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!