This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RMI 002 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "RMI 002" Watch "RMI 002" New topic
Author

RMI 002

Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
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.

Hi,
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:

and

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
make:
gen1.exportToRmi(port)
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(...)
explained?
I've retrospectively filled in some of the answers above.
Thanks,
Javini Javono
[ January 25, 2004: Message edited by: Javini Javono ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI 002