Guido Tapia

Helen.

Just do a 'wiki' search on www.sourceforge.net There are a large number of wiki systems available.

Last time I looked, EJB testing was in its infancy, however web services and servlet tests worked great.

Hi all,
I was just wondering what people's opinions are on uncaught exceptions (ThreadGroup#uncaughtExceptions). Should we bother about these? I mean its nice to have a nice dialog pop up on the client when an uncaught exception occurs on the server, but this opens up a can of worms that I'd rather not deal with.
Is this necessary to get full marks on the Exception Handling section of the assignment or is it beyond the scope?
Thanks in advance
GT

What DB file does it access? Does it assume that the current working directory will have a file named [whatever your file is called], or is there some way to configure this?
This can be configured via the suncertify.properties file which is modifyed in the GUI. and I also have a way of detecting a non existing or currupt db file when the server starts up and then I prompt the user for the db location.
Not sure what this means - seems very strange to me though. How does a client run in server mode? Aren't those opposites?
When the client is in server mode it tries to connect to a Server (via RMI) in alone mode it simply looks for a database file, again this file is specified in the suncertify.properties.
The point of my original message was simply that I have 2 commands to start my respective applications, one for the server and one for the client (the GUI application). Which is what I interpretted from the requirements, which differs from BillLeightons interpretation and I'm not sure who is correct.

I've interpretted that requirement differently. I assumed it only applied to the Client program, not the server program. My server program takes no arguments and just rund. Eg. java Server. My client however runs in either local or server mode. And the flags are server, alone or nothing, where nothing = server.
I dont know which interpretation is correct, but it just doesnt seem right to start the client and server from the same command.

I'm gonna try and find a way of interrupting System.in and what im gonna do is something like this.

Server Initialising

Press Enter to modify Settings (wait 3 seconds)

If user pressed enter go into console setup otherwise continue server initialisation.

I think this could work. Just dont know if you can interrupt System.in, maybe I can just have a separate Thread waiting on System.in and after the timeout I simply ignore any user input although this would block the System.io.read hmmm, Gonna try to find a way of interrupting the System.io.read

You shouldnt do client-server communication in the AWT Thread. Its a badly looked upon practice and in an assignment such as this I think its better to be as accademic as possible. What you should do in your GUI is something like this.

.....CODE..... button.addActionListener(new ActionListener() { public void actionPervformed(ActionEvent e) { new Thread public void run() { doAction(); } } .....CODE.... public void doAction() { try { server.startServer(); } catch (WhateverException we) { //show pretty dialog } }
Thats what I reckon anyway, its not a hard way to do it and its pretty clean. Oh, you should also consider dissabling the GUI prior to starting the new Thread and re-enable it when the action is complete (or in case of an exception). Also remember swing is not thread safe (look at) SwingUtilities.invokeLater
GT

Thanks Jim
But as much as I would have liked to have a server that takes in dblocation port ect we cant due to the assignment limitations.
In various places through the assignment we are told that we can only use one command line argument.
1) "The operating mode is selected using the single command line argument that is permitted."
2) "Your programs must not require use of command line arguments other than the single mode flag, which must be supported. Your programs must not require use of command line property specifications. All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory."
Which is no problem for the Client as we can take in all parameters through a GUI. but in the server specifying things becomes more difficult and i think its a horrible design to let the client set the db location for the server. I was thinking of when starting the server just having questions in the console like
- DB Location:<current db location>
Would you like to change this? (Y/N) But again I think this is horrible.

I thought about that. and yeah I initially had a default constructor that passed the other constructor a hard coded db file location, but then I thought that that was a poor design so i removed it. I'm also under the impression that the Data class will be used for auto testing, but its not too hard for them too see that they need to pass a File in the constructor. I'm sure that if they had a really strict auto-testing app they would have put the requirement for a default constructor in the specs. But still this is speculation as I havent submitted my assignment yet, but I'm going with the no-default constructor approach unless someone can share some more light on this issue.

I didnt provide a default constructor to my Data.java, this wasnt specified in the specs. I have a sole constructor taking in a File object (referencing the database file). I also have another class that uses the data class, basically a Wrapper and Im using a Record objects to encapsulate the database fields in an Object rather than using String arrays everywhere.

Hi,
I've found a couple of ambiguities in the spec.
1) When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
java -jar <path_and_filename> [<mode>]
But then later it goes on to say that there can only be one jar file.
Does this mean that we can specify the file for each mode? Eg "java -jar runme.jar Server" and "java -jar runme.jar Client"
2) In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used
We already have a command line argument that specifies if we are using a local database do we need to provide another method of specifying this.
Also when running the server, do we need to prompt the user for the db location? or should this just be set through the client?
Thanks

Hi,
Just polishing of my server and was looking for a few comments or suggestions. Currently I have a single Server object (RMI) that has the methods, findAll, find(criteria) and bookRecord. And basically this Server class handles all calls to the Data class in a synchronized manner.
I was thinking of adding a ClientRegister object to keep a handle on all the clients and this way I will be able to notify the clients of changes in the database (by other clients). I dont know if this is neccessary or even preferable. It just seems that my current Server is way too simplistic. Can anyone give me any guidelines especially with regards to how the 40 marks for the server are distributed. All I know is that my 50 line server seems not worth 40 marks.
Thanks

Thanks for the quick response Eugene.
Ok, Ill make my GUI simple with basic functionality like menus.
Thanks for that
GT

Hi all,
I was just wondering how far I should take my user interface. I have sortable tables and special panels for some of my components (they hide themselves) but I feel like I'm taking things over the top. The spec says simply that the results of a search need to be displayed in a JTable and if you don�t get any extra marks for having a funky UI then maybe its safer to have a very simple UI (no toolbar, menu bar, status bar, etc). Does anyone know if extra UI functionality is marked favourably or should I just make it as simple as possible as long as it meets the requirements?
Thanks

Apologies for the length of this post.
I'm currently polishing off my assignment and I'm thinking of changing my Data Access design. Currently I have the Data class implemented as per the specifications provided. But I have built a Facade over this that keeps the database information in memory and update both (memory and database) when an updates (deletes, etc) are made.
The benefits of this are ofcourse performance (especially for just reading) and the ability to hide many complexities of the Data class, such as working with a Data object rather than String arrays.
However I have had to map (hard code) the schema information in my Data Object so as I know where the name, location, etc goes in the record. This seems like a poor design as I have now stopped my database schema from being changed. I have also put a limit of the number of records that can go in the database (since I am using memory) this also seems like a flaw.
What I was thinking of doing now is to keep the Facade but only as a conduit to the Data class. This means that I will lose the performance benefits but will still be able to use Data objects rather than String arrays.
Any comments? Suggestions?
Thanks.
GT