David Mullens

Hi James,
RemoteDataInterface extends remote. DataInterface does not. I implemented DataInterface in the Data class (so I didn't want it to extend Remote).
Dave.

I don't have the code in front of me, but I do believe DataInterface methods throw RemoteExceptions. I thought a long time about how to do this and decided to allow them to.
My Data.java file _does not_ throw remote, nor does it import any rmi classes. When you implement an interface, you can throw less exceptions than you do in your interface. That is what I did.
Not sure if it is solid design (although I like it better than throwing java.lang.Exception), but I ended up feel it was the best way to do it (for the design I used).
Dave.

Hi,
I'll try answering your questions...although others on here might be able to do a better job

1. if RemoteDataInterface extends the DataInterface AND remote, does it override the methods in DataInterface?
2. Do the methods in RemoteDataInterface throw RemoteExceptions?
3. When the DataServer implements RemoteDataInterface do the implemented methods throw RemoteExceptions?

1). I wouldn't say it 'overrides' them. I would say it implements them. The Interface is abstract, so there are only method signatures. Nothing to override.
2). There are no methods in remote interface. Just this:
import java.rmi.*; public interface RemoteDataInterface extends DataInterface, Remote { }
3). Yes.
I know the answers are short....hope they help you out though....
Peace,

Dave.

Hi All,
In the specifications, it says that our Data client will implement the same public methods as the Data class.
So...what is expected in the way of documenting this in the Data Client. The logic is still in the Data class. Part of me just wants to copy the same JavaDoc from the Data class and put it in my Data Client...then the other part of me wants to basically say the method in the Data client simple class the method calls the method in the data class.
Any insights are appreciated.
Dave.

I'm using a command pattern. For my command objects, I implemented a command interface and in the constructor took whatever parameters I needed to perform the behavior. Sometimes this meant passing a reference to the table.
In my client, I simply added the listner I wanted passing in a new command object (which was taking whatever the command object needed).
I'm finding as I proceed with my project it is _very_ easy to add the same command object (say book flights) to my client in various areas (such as a menu bar, a JButton or a JToolBar.)
Hope this helps some...it sounds like you are on the right track.

Hi All,
This is not a real important question, but I'll ask anyway....
Now that Java 1.4 is released, are you planning on using it for your assignment?
I'm guessing our choices are JDK 1.2, 1.3 or 1.4.
Dave.

Hi,
You might want to take a look at the classes that Sun provides with the assignment. They have included all the classes needed to get the data from the database and even modify it.
The first thing I did when I download the assigment (after reading the requirements) was to create a simple command line based test client. All the test client would do is read the data from the database and print it out to the screen.
Hope that helps some...
Dave.

Steve, that is the question I have. Is it okay to change the signatures of the lock/unlock methods?
I know many on this forum have said they changed the signature and pass, but that isn't really my question. I'm sure you can pass by changing the signature, but do you loose points by changing the signature.... I'll need all the points I can get <grin> and if changing the signature means I'll have points deducted, I would much rather leave the signature alone.
I've read a post by Gregory Garrison on the forum, who passed with a perfect score on the server portion. I don't believe that he changed the signatures (I don't think he tracked a Client ID either). So, it seems, he didn't loose any points by not tracking a client ID and leaving the signature of lock/unlock the same.
I'm not saying that by changing the signatures one will loose points...I just don't know. I would think the design document and your reasons for doing it one way over the other probably plays a big part....
Dave.

Hi Jennifer,
I too found RHE very helpful. However, I think the best thing to do is spend the $250 and download the assignment! (I'm assuming you haven't started on the assignment yet). Why do a 'practice' application when you can work on the real thing
You will find a lot of help on this forum. If you passed your programmers, then you are probably ready for the developer's. The difference (in my opinion) is the Developer's stresses more design type decisions.
I am finding the Developer's easier and more enjoyable than the programmers....but then I like programming more than taking tests
Peace,
Dave.

No user id to lock the db - it's not needed - if you understand threading you will know this is true.

Hi Gregory,
I kind of understand threading (but I guess not well enought ). When I was doing my testing, I was able top successfully unlock a record that I had not locked. Basically I created 6 threads that would book some seats on the same flight. I think started 3 of those threads and created a new object that called the lock method directly (since it was accessable in my Data client per Sun's specification).
The new object was able to unlock a record that it had not locked. So, I ended up using the thread id (or whatever you call it) to keep track of things.
Not sure if that is the best design, but it seems to be working okay and I don't have to change the signature of the methods.
If you have any insight (or links) let me know. I've looked at threads, but I think I just need more experience using them.
thanks,
Dave.

Thanks guys!
Mark, I'm sure the reason Sun doesn't let people know where _exactly_ they lost points is keep people like me guessing on what exactly to do!
Gregory, thanks for the information. I noticed elsewhere that you got a perfect score on the server portion. Great job! I guess putting the private method in the Data class didn't cause any trouble then.....
Dave.

I believe that it fits within the requirements of the assignment to track the connection id. In fact, that is what my requirements doc from Sun says in the unlock section.
So, I'm keeping track of the Thread. Yes, I know (from other topics on JavaRanch) that RMI does not guarantee that it keeps the same connection for the same thread. However, I believe using the Thread is a better option than having to change the signature of the lock/unlock methods. I feel, that for this assignment, keeping track of the threads will suffice...
Dave.

Thanks for the reply Mark.
I guess I don't understand why adding private methods would mean that I should extend the Data class. For some reason, I've been uneasy about extending the Data class. I could see that if I was adding new functionality Iwould want to extend it, but all I'm doing is adding to the Data class, the functionality it is suppose to have.
Thanks for all the insights.
Dave.

Hi,
Is it okay to create private methods in Data in order to help with the findCriteria method?
Is it also okay, to create a class, that could help with the findCriteria method (I haven't done this, just looking at options)?
Thanks for any insights.
Dave.

Thanks Rajesh!
I need someone to push my design decisions! I had thought about creating "command classes" that implemented the various listeners. I decided against that. I wanted to be able to create an object that knew how to excute it's own command (so to speak) no how it was going to be used.
In my client class, I have two inner classes. One implements ActionLister, the other extends MouseAdapter. By leaving the command classes generic (by only implememnting a CommandInterface) I was able to pass in the same command object to both inner classes constructors. That way, in actionPerformed() I could do a command.execute() and also in mouseClicked() I could do a command.execute().
I can also pass any command class that implements the CommandInterface and it should work. So, I get rid of all the if statements and just do an .execute() and the object takes care of the rest.
I tried to follow the command pattern in the book "Applied Java Patterns". Not sure if I got it right, but it seems to work okay.
Dave.