Todd Harney

Greenhorn
+ Follow
since Jan 25, 2002
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Todd Harney

I think you should read the requirements and figure it out. It's not much of an accomplishment to have everyone tell you step by step what to do next.
My $0.02 worth,
Todd Harney
I think it's perfectly legal to include the lock and unlock methods in the remote interface. We are to expose the public methods of the Data class which is where lock() and unlock() are usually added. There's more to the story than that, but by using a UnicastRemoteObject not bound in the registry, you can guarantee the uniqueness of each client and handle the lock and unlock logic (part of it requiring client uniqueness) there.
Just a thought.
Todd Harney
Yes you will get two copies of the EXACT same data class...but server.jar and client.jar shouldn't be extracted. Only the main submission jar file should be extracted and then the server.jar and client.jar files will executed by java -jar server.jar for example.
Hope that helps,
Todd
Steve,
Can you be more elaborate about how you created the JAR file? Did you use the jar command? Or did you use Winzip?
Also, the CLASSPATH setting shouldn't matter. On my windows machine here at home, I have only modified the PATH and CLASSPATH to include my Java path information. I didn't even add anything like server.jar or client.jar to my machine. And I can run the jar file from any directory using java -jar server.jar.
Any additional input would help!
Thanks,
Todd
Mark,
The link you provided didn't help me any. I did a search on user guide and found nothing of interest except discussions on JEditorPane. I am just trying to decide what to write for the "user documentation for the database server and the client gui". Did you write a separate HTML user manual for the client and database server, or does the spec just re-iterate the fact that we need to write in the README how to start and stop the server and client?
Confused,
Todd
Mark,
My client consists of something of the following:
FBNGui.java - contains all code related to visuals like layout managers, tables, buttons, etc. But it also contains several inner classes that are extensions of AbstractAction...i.e, they are action classes, but have been separated out into inner classes to keep the action code from cluttering the visual code. Also contains inner classe for my table model.
FBNServices.java - there are other files too, but this a "business" type interface and factory that the gui code calls like bookFlight and searchFlights...called from my actions classes.
I kept things in the gui as inner classes to avoid passing around references to gui widgets to get data and what not? Does this design seem reasonable to you?
Thanks,
Todd
Gregory,
I am currently in the process of writing the user guide for the client and server. How much detail are we to provide in those guides? For the client user guide, did you just document how to search for flights and how to book a flight? What about the server? Just how to start and stop? Also, did you provide a directory in your submission with all of your compiled code and then also the server and client jar files?
Thanks in advance,
Todd
Mark,
So you had the client.jar and server.jar in the root of your submission and also the db.db file? Then you mentioned in the README.txt that the db.db file needed to stay there?
Am I guessing correctly?
Thanks,
Todd
PS - Also, how does the whole "user.dir" thing go? I thought it depended on platform to platform? Is there some rational pattern behind where "user.dir" will point to?
For anyone who has implemented a GUI for starting and stopping the server, did you use a JFileChooser component to allow selection of the database file? The reason for asking is that the JFileChooser takes a long time to load on a machine that has a lot of drives mapped and a lot of storage space to cover to create its internal file mapping.
Is a simple text field enough?
Thanks,
Todd Harney
PS - I have seen people mention the system property for user.dir...so where are you telling the graders to put the db.db file? Can you predict on any platform what the user.dir property will evaluate to?
that is correct that the Data class will need to be in both jars (client and server), but I don't think is 'copy and paste' like you said. There is still only one Data class, you just add it to both jars when you make the JAR file(s).
Thanks,
Todd
You create you application jars (like client.jar and server.jar), but you package those all up into a single jar file for submission. I believe the requirements page details that somewhere?!
Thanks,
Todd
I think I see now...
Each remote connection has its own set of locks for itself...this way we can guard against some other client trying to unlock a record that wasn't his, right?
Let me know if I am way off base here.
Thanks,
Todd Harney
Mark,
Did your facade class then implement the Data access interface? Or did it contain an instance variable of type DataAccess?
Thanks for the help!
Todd Harney
PS - Regarding the lock manager class, you're saying that the lock manager itself has a mapping of record numbers to connection objects? And then each connection object has its own mapping as well? I guess I was not clear on that point. My remote data connection has a reference to the data class and the lock manager class. I thought I was just going to add a lock, let's say, for record 1 in the mapping with the connection object as the value...effectively mapping each locked record number to a presumably unique remote data connection object reference. Is that not correct..or is it misguided?
Hello all:
My design is very similar to the one just discussed where I have a RemoteDataConnection class that is a remote object, but not bound to the RMI registry...so each client asks the connection factory in the registry for a remote connection and is issued a reference to a new RemoteDataConnection(data,lockManager) which lives on the server. (data and lockManager are instance variables that come from the connection factory). So, I am having two issues that I would like some insight into:
1) It has been mentioned that we don't need to change the method signatures for lock/unlock to include a "client id" (specifically if we use the connection per client model) Isn't true however that since there is only one locking instance for each data instance that there will need to be some adapter code to map the record number to the connection object? (like in a HashMap?)
2) It has also been mentioned that a business interface is a bad idea as it is not re-usable. In my design, the GUI speaks only to a business interface that defines methods like bookFlight, searchFlights, etc which in turn invoke the appropriate methods on a DataAccess interface (either local or remote). Is this against the requirements set forth by Sun? Should I remove this interface and go with a DataClient that implements DataAccess, but adds methods like bookFlight, searchFlight, etc?
Any comments/suggestions would be appreciated!
Thanks,
Todd Harney
Hello all:
My design is very similar to the one just discussed where I have a RemoteDataConnection class that is a remote object, but not bound to the RMI registry...so each client asks the connection factory in the registry for a remote connection and is issued a reference to a new RemoteDataConnection(data,lockManager) which lives on the server. (data and lockManager are instance variables that come from the connection factory). So, I am having two issues that I would like some insight into:
1) It has been mentioned that we don't need to change the method signatures for lock/unlock to include a "client id" (specifically if we use the connection per client model) Isn't true however that since there is only one locking instance for each data instance that there will need to be some adapter code to map the record number to the connection object? (like in a HashMap?)
2) It has also been mentioned that a business interface is a bad idea as it is not re-usable. In my design, the GUI speaks only to a business interface that defines methods like bookFlight, searchFlights, etc which in turn invoke the appropriate methods on a DataAccess interface (either local or remote). Is this against the requirements set forth by Sun? Should I remove this interface and go with a DataClient that implements DataAccess, but adds methods like bookFlight, searchFlight, etc?
Any comments/suggestions would be appreciated!
Thanks,
Todd Harney