Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RMI Exceptions RecordNotFoundException

 
stefan andersson
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all!

I've pretty much rounded off the RMI part of my project. All that is left is handling the generic exceptions that are thrown such as RecordNotFoundException.

I have 2 business-method adapters, both contain find() and book(). They are called LocalDataAdapter and RemoteDataAdapter. RemoteDataImpl wraps an instance of the Data class. Inside the find() method in RemoteDataImpl, I call methods in Data that throw RecordNotFoundExceptions.

Hence, the RemoteDataAdapter must also throw RecordNotFoundExceptions.

The problem is that the RemoteClient on the remote machine that calls find) in RemoteDataAdapter has no clue what a RecordNotFoundException is.

All that I have copied to the remote client are the stub, the remote adapter and the client class.

Every time I run the client on the remote machine, it throws an error stating that it can't find RecordNotFoundException.

How can I solve this problem?

Thanks!

/Stefan
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by stefan andersson:
Hi all!

I've pretty much rounded off the RMI part of my project. All that is left is handling the generic exceptions that are thrown such as RecordNotFoundException.

I have 2 business-method adapters, both contain find() and book(). They are called LocalDataAdapter and RemoteDataAdapter. RemoteDataImpl wraps an instance of the Data class. Inside the find() method in RemoteDataImpl, I call methods in Data that throw RecordNotFoundExceptions.

Hence, the RemoteDataAdapter must also throw RecordNotFoundExceptions.

The problem is that the RemoteClient on the remote machine that calls find) in RemoteDataAdapter has no clue what a RecordNotFoundException is.

All that I have copied to the remote client are the stub, the remote adapter and the client class.

Every time I run the client on the remote machine, it throws an error stating that it can't find RecordNotFoundException.

How can I solve this problem?

Thanks!

/Stefan


You must build both your client and server as the same program, this program decides what to run as based on the presence of the server argument on the command line. IF you build it this way the client has access to all the database classes, this is actually needed as well to run in standalone mode.
 
stefan andersson
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Peter!

I'm not sure I'm following you. The client that calls the server classes is on a remote machine. If I understand RMI correctly, all that is needed on the client machine are: the stub, the adapter and the client class.

Isn't that all that is needed?

Since remoteDataImpl wraps a private Data.java object (the class that implements the DBMain interface) and that remoteDataImpl uses Data, which throws RemoteDataExceptions, do I have to copy the RemoteDataException to the client machine aswell?

It seems to defeat the purpose of remote calls if I have to copy every class I ever use on the server side to the client side...
 
Matt Sheehan.
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What Peter is saying is that you call the server this way:
and you call the client this way
Therefore, both the server and the client are using the same runme.jar and both have access to all classes.

If this wasn't the case, you could use dynamic class loading to get what you need, but in my spec it says:
You must provide all classes pre-installed so that no dynamic class downloading occurs.
 
stefan andersson
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, so it sounds like as if I may have missunderstod the entire rmi part...

If the jar file contains everything the remote client needs, why bother with stubs etc...? Just point to the remote database file and you're done...

What I can't understand is where the actual database file should lie, my exam states "the program must allow the user to specify the location of the database".

The way I see it:


DATABASE FILE

| |
DATA DATA
| |
RemoteImpl LocalImpl


If a remote client is started how is a remote server instantiated on a different machine, how should the rmi be started?
[ November 24, 2004: Message edited by: stefan andersson ]
 
Matt Sheehan.
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the jar file contains everything the remote client needs, why bother with stubs etc...? Just point to the remote database file and you're done...

You must point to your DB interface or something higher since it is responsible for maintaining file/record locks for simultaneous multiple clients.
What I can't understand is where the actual database file should lie, my exam states "the program must allow the user to specify the location of the database".

You must allow the user who starts the server to specify the file path to the database file, maybe using a JFileChooser, for example.
If a remote client is started how is a remote server instantiated on a different machine, how should the rmi be started?

The client and server each have their own identical copy of runme.jar. The client doesn't have to start the server, its understood that a server must already be running on the specified IP and port or else the client wont work.
[ November 24, 2004: Message edited by: Matt Sheehan. ]
 
Stephen Bloch
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't actually requested an SCJD test yet, so I don't know how the requirements are worded... but in the Real World, wouldn't it make sense to deliver two separate jar files, one with all the classes the server needs (and a main class that starts the server) and one with all the classes the client needs (and a main class that starts a client)? Some classes, e.g. anything that's serialized for communication between the two, will necessarily appear in both jar files, but that doesn't seem to me like a terrible price to pay.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stephen Bloch:
I haven't actually requested an SCJD test yet, so I don't know how the requirements are worded... but in the Real World, wouldn't it make sense to deliver two separate jar files, one with all the classes the server needs (and a main class that starts the server) and one with all the classes the client needs (and a main class that starts a client)? Some classes, e.g. anything that's serialized for communication between the two, will necessarily appear in both jar files, but that doesn't seem to me like a terrible price to pay.


In the real world its often the case that the client and server are not even supplied by the same organization. One might be a Solaris server running J2EE and the other a Microsoft client running IE6. The protocol could be an industry standard like HTTP.

In the SCJD assignment the client and server are specified to run from the same jar file and to also support a standalone mode where there is no networking. The networking is required to be either RMI or sockets. The data is required to be serialized Java objects. There are a number of restrictions on RMI, such as no dynamic class downloading and no IIOP.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic