NX:Contractor About RemoteException

[Wayne Yang]

In my assignment the instructions require:
The data access file must be �Data.java� and must implement the following interface DBMain:
public String[] read(int recNo) throws RecordNotFoundException
public int [] find(String [] criteria) throws RecordNotFoundException
����
So my Data class in which the data access methods are finished implements the interface DBMain. I plan to use DBMain to be the data access interface at client side. In my implementation of rmi, my remote interface DBMainRemote extends Remote and DBMain.
public interface DBMainRemote extends Remote, DBMain
And in my DataRemote class that implemented the interface DBMainRemote and it also has a reference to a Data instance to do actual data access operations.
public DataRemote extends UnicastRemoteObject implements DBMainRemote
However, a remote method must throw RemoteException or its superclass (IOException or Exception), because according to the instructions the method declarations in the interface DBMain are unchanged, where RemoteException can be included?
Any suggestion?

[Andrew Monkhouse]

Hi Wayne,
Welcome to JavaRanch.
This thread might give you some ideas about a totally different way of handling it.
Regards, Andrew

[Werner Joerling]

Hi Wayne,
you need more interfaces. Here is another thread dealing this problem.
https://coderanch.com/t/183727/java-developer-SCJD/certification/NX-DBAccess-RemoteException
Werner

[Wayne Yang]

Andrew and Werner, thank you for your quick response! What I understand is that another interface has to be defined to solve the problem. Suppose that another interface called AnotherDBMain is defined as follows:
public String[] read(int recNo) throws RecordNotFoundException, RemoteException
public int[] find(String [] criteria) throws RecordNotFoundException, RemoteException
����
In addition, another adapter class which has a reference to a Data instance as its member variable is also needed to implement the new interface AnotherDBMain. Actually the implementation of methods in the new interface AnotherDBMain depends on the data access methods of the Data instance.
public class DataAdapter implements AnotherDBMain {
private Data data = new Data();
public String[] read(int recNo) throws RecordNotFoundException, RemoteException {
return db.read(recNo);
}
}
In the implementation of rmi, the method declarations of those classes and interfaces should look like follows:
public interface AnotherDBMainRemote extends AnotherDBMain, Remote
public class DataRemote extends UnicastRemoteObject implements AnotherDBMainRemote
A DataAdapter instance is included in class DataRemote as a member variable to do the actual data access operations. At client side AnotherDBMain is used to be the data access interface.
Am I on the right trail?
And before reading the posts, I think it is unquestionable that extra methods can be included in Data.java. However, now I am lost. I cannot read out such an implication from my instructions. I want to know whether on earth extra methods can be added in Data.java.

[Andrew Monkhouse]

Hi Wayne,

Am I on the right trail?

Looks good to me.

And before reading the posts, I think it is unquestionable that extra methods can be included in Data.java. However, now I am lost. I cannot read out such an implication from my instructions. I want to know whether on earth extra methods can be added in Data.java.

That is the nice thing about getting into these discussions - you can find so many opinions as to whether something is allowed or not
I think the majority of people here agreed that you could add extra methods to your Data class if you wanted to. However you could not add those extra methods to the interface provided by Sun.
Regards, Andrew

[Wayne Yang]

Andrew, I really appreciate your help! It seems to do the trick.

I have sent an email to Sun and once I get a reply from Sun I will post its reply.

[Wayne Yang]

I got a reply from Sun today. Sun said "Yes, Data.java may contain methods that are not in the interface."

[Andrew Monkhouse]

Hi Wayne
Thank you for letting us know. It is good to have our ideas confirmed.
Regards, Andrew

[josine wilms]

It's now 2006... Thanks all very much for sharing your findings on this problem with it's seemingly awquard solution !!

Josine