defaulting DB file location - B&S

[Dan Murphy]

Greetings,

My understanding is that when the application is run in networked mode, the path to the DB file cannot be specified by the client as this would require them to be able to browse the filesystem of a remote machine. Therefore, in networked mode, I assume a default location should be used? My assignment instructions state that the database file must be in the root of the submitted JAR file, so I assume that it is this DB file which I should default to?

If my JAR file is located at "c:\scjd\bs.jar" and the DB file in the root of this JAR is named "db.txt", then will the following code find the DB file if the the current directory when the JAR is executed is "c:\scjd"?

String currentDir = System.getProperty("user.dir");
File dbFile = (currentDir, "db.txt");

I assume this would work fine if db.txt was located at "c:\scjd\db.txt", but I don't know whether this will work if db.txt is in the root of a JAR file in "c:\scjd"?

Clearly this wouldn't work if the user executed the JAR file from anywhere other than "c:\scjd", but I presume this restriction is OK as long as I make it clear in the instructions for running the application?

Thanks in Advance,
Dan

[Zee Ho]

actually, when running the netclient-server mode, the reviewer need accomplish 2 steps

1. he should start the server and done all the deployment in server machine locally rather then specify it in the client side. so, you can have the access right to the file system of that machine.

2. he should start the client in another machine(or he can start in the server machine with localhost and the port, who cares? ), here, he should specify the host address and port on which the server run.

so I think, you don't need to "hard code" the database path in your application, you can let the one who deploy the server side to choose it freely.

hope this can help.

[Paul Bourdeaux]

Zee Ho is correct. When you start the server, you specify the location of the datafile. When you start the networked client, you just need to specify the address (and possibly port number) of the server.

[Dan Murphy]

Hi,

I don't understand how I can choose the location of the DB file if I'm starting the server on its own because:

- there is no GUI that the user can use to choose the file
- the only command line parameter I'm allowed is <mode>
- manual editing of property files is not allowed

So how do you specify where the DB file is

Best Wishes,
Dan

[Zee Ho]

I don't know whether there's something like "all the configuration should be done via ui and stored in the file named xxxxx", at least, I have, I think you can start up a UI to let client choose the port, host, log file (if u like) and etc. you can design the ui as simple as a Jframe which only contains only 2 JTextField, maybe you can take a look at the JFileChooser, It will make your UI looks so cool. after client confirm all what he filled in, you can save all those to a propertis file and start the main frame which contains the JTable and something else. Now, any time you want the database path, extract it from the properties.
[ April 10, 2005: Message edited by: Zee Ho ]

[Dan Murphy]

Using a JFileChooser doesn't enable the client to chose the DB file when running in networked mode because you can only browse the local filesystem with this component. As far as I can see, if you're running in networked mode there is no way to choose the database file location because:

- you can't do it from the client, because you don't have access to the server's filesystem

- you can't do it from the server, because (in my assignment at least) there is now way to specify it - no gui, no commandline parameter, and no manual editing of files

So it seems to me you need to use a default.

Cheers,
Dan

[Frans Janssen]

Originally posted by Dan Murphy:
- you can't do it from the server, because (in my assignment at least) there is now way to specify it - no gui, no commandline parameter, and no manual editing of files

Hi Dan,

Does your instructions specify that you cannot use a GUI for your server? Mine didn't and so I used a GUI (including a JFileChooser) to specify the file location for the server.

Frans.

[Steve Taiwan]

In my project, when the application is run on server mode, JFileChooser pops up
and requests a user to locate DB file. But in client mode, JFileChooser doesn't pops
up so the user can't input his db file location. I don't think the project request
a user to locate db file remotely.

[Paul Bourdeaux]

Hi Dan,

Why are you assuming that you cannot have a GUI for the server? Unless it is specifically forbid in the instructions, there is no problem with using one. In fact, I have never heard of I being done differently...
[ April 11, 2005: Message edited by: Paul Bourdeaux ]

[Dan Murphy]

Hi,

Thanks for your replies. I guess I just assumed that I shouldn't use a GUI for the server, because there is no mention of a server GUI in the instructions, and in the Denny's DVDs example in Max's book, no server GUI is used. Looks like I'll have to revise that assumption

Cheers,
Dan

[Ian Perkins]

Hi,
There is something that worries me here... the assumption that there can be a server gui also presupposes that the server software will be running in Windows or similar where Swing painting operations have an implementation.

If I try to run a Java gui on the HP-UX machine at work I will get some very angry error messages. The only front end is via a Telnet connection handled by some kind of terminal emulator. Write-Once-Run-Anywhere does not really apply IMHO.

How do I know that the Sun examiners will not try to run my server on this type of setup?

Thanks for any comments...
Ian

[Dan Murphy]

I guess you can assume that the application will be run on a system which does support GUIs, otherwise how would they test the client?

Getting back to main topic of this thread, there doesn't really seem to be a consensus about whether you should be able to configure the location of the database file via a server GUI. It would be great if this website had the ability to hold referenda, so that we could get an idea of the percentage split on these contentious issues.

One website which does provide this functionality is
smartgroups I'm sure there are many others, and it may even be possible to download the necessary code/components from....somewhere....

Cheers,
Dan

[Ian Perkins]

I guess you can assume that the application will be run on a system which does support GUIs, otherwise how would they test the client?

This is precisely what worries me. I think that a client/server type setup implies two different physical pieces of hardware (otherwise why bother, just run always in local mode). I plan to test with a Windows laptop client connected to a pc running Linux. Testing both components on one piece of kit is not extensive enough and, in my experience, does not reveal all the subtle bugs especially in a sockets based implementation like mine.

*Most* servers in a real-life situation will be Unix/Linux machines which would perhaps also be running a web-server app as well as perhaps hosting a database layer etc etc. Typically they do not need to support a GUI.

I guess the answer is the same as in many other threads - make a decision and document the reasons - but I am still curious as to how the examiners test our software. If they expect true cross-platform transparency (which I believe is an implicit goal of all Java development) then a server-side GUI is going to fail dramatically under certain conditions.

Thanks anyway for the feedback

Ian

[Frans Janssen]

Ian,

You probably worry too much. I submitted by solution with a GUI for the server and received full points for the server part.

So I guess you can assume that GUI capabilities are available to the server.

Frans.

[Paul Bourdeaux]

Hi Ian,

I understand your concern, but I don't believe it is a problem for this assignment. many others have used a GUI for their server and passed without point loss.

If you want to be sure, send an email to [e-mail] and ask them. After you do, include their response in this forum.

[Paul Bourdeaux]

*Most* servers in a real-life situation will be Unix/Linux machines which would perhaps also be running a web-server app as well as perhaps hosting a database layer etc etc. Typically they do not need to support a GUI.

Yep, and if this were a real life situation I would have the server code attempt to use a GUI, and if exceptions are thrown, revert to a text user interface. This is what the majority of "real life" server applications do anyways (at least the ones that are worth a crap!). If you really wnated to be snazzy you could do the same (it isn't all that hard). But remember that extra points re not given for going above and beyond, and this is also not a real life situation...

[Ian Perkins]

Thanks Frans, it's good to know this worked for you...

I think I will continue anyway with my decision to rely on the properties file with either notepad or vi as the front end!

Ian

[Ian Perkins]

Hi Paul,

This is what the majority of "real life" server applications do anyways (at least the ones that are worth a crap!).

Uh, Apache Tomcat anyone?

[Paul Bourdeaux]

Originally posted by Ian Perkins:
Thanks Frans, it's good to know this worked for you...

I think I will continue anyway with my decision to rely on the properties file with either notepad or vi as the front end!

Ian

Be careful here Ian. You CANNOT require the existance of a properties file. If one exists, you should use it, but if one doesn't exist, you must be able to dynamically create it. I have seen others get an autofail for this. i will try to find the post for you.

[Paul Bourdeaux]

Here is the post I was talking about... Hanna's Story

[Paul Bourdeaux]

Originally posted by Ian Perkins:
Uh, Apache Tomcat anyone?

Really? You have trouble running tomcat in a text environment? I have mind running in a Unix shell with only text interface.

[Ian Perkins]

Hi Paul,

Many thanks - I thought I had could understand the spec but I had made exactly the same mistake as Hannah.

I owe you a virtual beer!

Ian

[jiju ka]

My assignment instructions state that the database file must be in the root of the submitted JAR file

I will take this statement as

1. Database file must be inside the jar file when you upload

2. The location of database file must be in the root of jar

for example if your jar root contains folders com/pack1/pack11 & com/pack3/pack31, db file should be at the same location where the folder com is.

[Paul Bourdeaux]

Yes, you must include a copy of the original, unchanged db in the jar you submit... however, you cannot assume that it will always be there. The assessor can (and has in the past) removed this file to see if the program still runs.