Oliver Weikopf

No, you may not include a jar for each version or deviate from the given syntax. The instructions are very clear there.

Use one main only. If you find no appropriate class to put it into, you might want to add a class called Startup or something and give it nothin but a main method that calls the main() appropriate for the arguments.

Originally posted by Edwin Dalorzo:
My worry is if the magic cookie in the file the evaluator is going to use is different from the one in my file. Because that would make the application start-up fail, or at least will prevent the user from starting the database server.

I was rather thinking about removing the magic cookie check, in order to avoid unforeseen issues during the evaluation.

The entire point of the cookie is to assert that the file you're using has the correct format. Leaving it out in case you're using the wrong file is a bit schizophrenic, don't you think?

I recommend making the check, that's what the cookie is there for. Also, I assume that during evaluation the db file you're including will be used, since they emphasise so much that you need to include it.
[ July 20, 2006: Message edited by: Oliver Weikopf ]

Wow, that's a lot of testing! I personally don't do many of these.

But for the cookie: The way I understand it, the cookie must always have the same value to identify the file as a file of the appropriate format.
So I took a look at the file, and noted the cookie. A file is only deemed to have the correct format by my Data class if the cookie has that exact value.

Sounds plausible. Guess I'll put a copy in the jar then.

Thanks a heap!

Originally posted by Mihai Radulescu:
Hi Oliver

How about :
[code]
final ClassLoder loader = getClassLoader();
final URL helpURL = loader.getResource("myHelp.html");
new JEditorPane(helpURL);
[code]

Regards M.

The problem with this is that the docs aren't in the classpath, so this won't find them. I'd have to include the files in the runme.jar for that, and that would mean including them twice, which doesn't sound like a good thing to do.

I include my help files (userguide.html and five others) in the docs folder as specified in the instructions.
I also display these same files from within the application, using a JEditorPane.

So far, I assume the docs folder is located below the working directory and get it like this:

File helpFolder = new File(System.getProperty("user.dir"), "docs");
Since I execute the program in the application's root, that's fine, but I cannot be sure it will always be used as the working directory.
My problem is that I have no idea how to find the folder if the working directory differs. Has anyone else encountered and possibly solved this?

I assume that the db file is in the current working directory as a default. I assume this is the case as we have to include it in our submission jar at root level. If it's not there, I pop up a message asking the user to set the correct file.
I wouldn't include it in the runme.jar and copy it out. Sounds a bit weird to me.

Sure, can't think of anything that's wrong with it. Actually, I'm doing it myself (although I'm currently still fighting a bug there).

I'm not sure I understand your problem correctly. If you use only one RA file (like I do), you'll definitely have to make sure that no two methods are called synchronously, as inside a method, you'll probably set the file pointer to a position and the read or write there. This is something you can't allow two threads to do at the same time. So, synchronizing your Data methods would be necessary, no matter whether RAFile is thread safe or not.

Originally posted by Sham Delaney:
Oliver, is there any benefit to using the way I am connecting...and the way you are connecting?

I guess not. I write it the way I do just because I find it more readable.

Use the following:

Registry registry = LocateRegistry.getRegistry(hostName, rmiPort); service = (ServerInterface) registry.lookup(serviceName);

Originally posted by Jeroen T Wenting:
It's effectively impossible to determine the actual client making a request.

Not only is it possible, I believe it's a requirement. You may argue that you don't need it for lock(), but you most definitely need it for update() and delete(). You must be able to determine whether the caller owns the lock on the record it wants before you allow either of these actions.

I had first implemented it in such a way that the client could not be identified, but soon found out that this didn't meet the requirements which say clearly: "Locks a record so that it can only be updated or deleted by this client." When I noticed this, I did a search on this forum for the expression "identify client" and ended up reading about this for hours. I recommend you do the same.

This thread contains a collection of threads (it's in Andrew's first post) that may be particularly helpful.

I ended up using the "one Data instance for each client" approach and it's working fine for me.
[ July 12, 2006: Message edited by: Oliver Weikopf ]

Either of the two approaches is acceptable. Just make sure you note this decision in your choices.txt.
I personally went for something in-between. I've got a Record object encapsuling the String array. I use only one Getter that expects an index. But I provide constants for the indexes. This way, I hardcode the database layout, but changes in the underlying data model are easily transported just by changing the constants.

Originally posted by Jared Cope:
I believe that in client mode you must still be able to select a local database, in which case the application will 'switch' to 'alone' mode (even though it was started without the 'alone' command line parameter).

Jared,

It doesn't say so anywhere. All it says is "the program" must allow this, not that client mode must. I allow the user to specify the local database file in either mode, but don't switch modes when he/she does.
Furthermore, "the program must accept an indication that a local database is to be used" sounds like the "alone" parameter to me.

But, as you said, either approach might be acceptable, and the specs aren't particularly clear, so it's something to note in the choices.txt and move on.

Originally posted by Thirumurugan Mylrajan:
So use command line parm to choose server or client and when the client opens you should be able to choose connecting to a local database or a network server.

Thirumurugan,

I disagree. There are three moodes.

Server - opens local database and provides it for clients. Started with "server"

Client - connects to a server, not to a local database. Started without params

Standalone - opens local database. No network connection. Started with "alone" param

So once you start the spplication, the mode defines what you can open. No further decision inside the application. If the client version allowed you to open a local database, there would be no point in having a standalone version.