aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S ConfigurationGUI DB location process/errorhandling in init Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S ConfigurationGUI DB location process/errorhandling in init" Watch "B&S ConfigurationGUI DB location process/errorhandling in init" New topic
Author

B&S ConfigurationGUI DB location process/errorhandling in init

Thomas Heiss
Greenhorn

Joined: Feb 20, 2008
Posts: 9
Hello all,

New server? Or was just the Germany->US Internet link broken yesterday?

I have a question regarding B&S server startup / client standalone startup, as an configuration GUI should prompt for the database location (at least one time).

My problem is right now, that for a good multi-tier architecture with layering I am using several classes which get instantiated UNTIL finally Data() with RAF reads the file with path from disc.

1. As the DBMain interface provides no setDBLocation(String) method, I wanted to go for the constructor Data(String dbLocationPath) way.

1.1 Usually this is no problem, when the ServerImpl creates in init() it's RMI RemoteDatabaseImpl, which would call thru another class the Data(String) constructor.
The requirement would be, that no exeption happens loading the database file (call path is from Main to Data including 5 classes).

Otherwise: The Application main class may not be able to startup. ServerImpl.init() could fail with FileNotFoundException.

Before calling in init() "new MyRMIRemoteDatabaseImpl(String dbLocationPath)" the requirement of course is, that the ConfigurationGUI asks for the correct location path (or reading from suncertify.properties).

1.2 But shouldn't I check, that Data class is actually able to load the database (and check it's magic cookie value), before I try to start in init() the full class hierachy including RMI, business object, Data and RandomAccessFile?

1.3 If there would be any error, init() would completely fail, making Main App with ServerImpl fail to startup (would abandon start completely).

1.4 On the other hand, I find it quite complicated, if I tried to create a Data(String dbLocation) instance in ConfigurationGUIController, just to see if loading the database file works here.

If it does, closing the configuration GUI, jumping back to ServerImpl.init() and call "new MyRMIRemoteDatabaseImpl(String dbLocationPath)" next; the already verified database location could then not cause the full class hierachy (constructors) to fail, aborting the successful application/server startup.

1.5 If I do not verify the given database location in the configuration gui panel before, I seem to run into the problem, how to handle the possibly upcoming errors while staying in the init() method (I also do not want to catch and loop).

1.6 My idea basically was to construct the object class hierachy (5 classes) from main() to ServerImpl.init() and if done, calling execute() from my main application, which would finally launch the RMI server.

2.1 Would it be the better way to call the configuration GUI in ServerImpl.init() but to let the GUI stay as long as the server is running (making a shutdown with button possible too)?
This would mean that the ConfigurationGUIController (inside ServerImpl) listens for the "Start"-ActionEvent and calls ServerImpl.execute() itself.
Wouldn't it be then the only requirement to move my call "new MyRMIRemoteDatabaseImpl(dbLocationPath)" from ServerImpl.init() to execute(), catching appropriate exceptions and letting the user to re-try to hit "Start" again?

2.2 Again, I would really appreciate a solution where I could instantiate all the required classes with dbLocationPath information in the ServerImpl.init() method and not in ServerImpl.execute(). But my constructor passing from one class to another seems to make it impossible, to correctly react on file I/O exception inside ServerImpl.init() and being able to re-try to call Data(String dbLocation) when the FileNotFoundException (or magic cookie not valid) exception was thrown.

2.3 A think a really weird solution would be to catch the exceptions in ServerImpl.init(), to re-try, which means to close and open the configuration GUI panel all the time, when an exception occured after closing the panel, to provide a successful "final startup"???!

2.4 Same happens for me in the client standalone mode, where instead of ServerImpl.init(), ...ClientStandaloneImpl.init() get's called, which also has to pass the String "dbLocation" thru another class to the constructor of Data(String dbLocation).

3. Hmm. Of course there is another solution.
Getting rid of the String "dbLocation" in all the class constructors and having a method like "initDatabase" in the Data class (which we are required to implement from SUN, which also implements DBMain).

But, that would mean on the other hand that I can not work with DBMain/Data directly as the interface and Data class DO NOT HAVE something like "initDatabase(String)" / "openDatabase(String").
I really think that my classes are already enough to refuse to introduce another DataAdapter class.

Anyone with any valuable ideas on this?

4. Searching for similar posts showed me that most seem to have a start/stop/connect GUI button, which seem to start the creation of the bunch of classes by calling their constructors.

But well, I am not sure enough, if that could fit quite good into my current class design and startup architecture.
Maybe it is okay for the client, but for the server side I usually dislike having up an GUI all the time (hmm well, which points me how to stop the RMI server without an GUI; maybe ShutdownHook?).
Hmm, all that stuff just because "-Dsuncertify.dblocation=xxx" is not allowed in spec

5. Should I really risk that the assessor chooses an invalid database location which my application is not able to automatically handle error for a re-try without having stopped the complete server and standlone client from startup? The assessor would then need to start the main application again

I can't believe it. SUN says 20h for a good programmer to a solution, 40h for a middle programmer and max 80h for a junior.
If >2 weeks something is wrong.

To be honest, it took me several days with great help postings on this forum to try to understand their specification

Best regards

Thomas

Pardon for my English and hey, already too many coffees and it is soo late here


Technical J2EE Solution Consultant<br /> - Specialist for Middleware and Messaging solutions --<br />Certified SCJP 5.0, SCBCD 1.3, SCEA I (SCJD, SCEA II/III running)
Alex Belisle Turcot
Ranch Hand

Joined: Apr 26, 2005
Posts: 516
Hi,

your post was very long, and not too easy to understand... Please try to discuss the comments I added:


1. As the DBMain interface provides no setDBLocation(String) method, I wanted to go for the constructor Data(String dbLocationPath) way.

=> ok..


1.1 Usually this is no problem, when the ServerImpl creates in init() it's RMI RemoteDatabaseImpl, which would call thru another class the Data(String) constructor.
The requirement would be, that no exeption happens loading the database file (call path is from Main to Data including 5 classes).

==> ok.. Data is only created when no exceptions are raise in its constructor

Otherwise: The Application main class may not be able to startup. ServerImpl.init() could fail with FileNotFoundException.

==> Then, your ServerImpl.init() can raise an Exception..


Before calling in init() "new MyRMIRemoteDatabaseImpl(String dbLocationPath)" the requirement of course is, that the ConfigurationGUI asks for the correct location path (or reading from suncertify.properties).

1.2 But shouldn't I check, that Data class is actually able to load the database (and check it's magic cookie value), before I try to start in init() the full class hierachy including RMI, business object, Data and RandomAccessFile?

==> If the file does not exist, wouldn't your Data constructor throw an exception ? And fail to be instantiated ?
==> And your init() would catch the exception and propagate it to the user
==> The user Interface might not let your go through..


1.3 If there would be any error, init() would completely fail, making Main App with ServerImpl fail to startup (would abandon start completely).

==> You should/must rather handle the error, not just watch it destroy your application


1.4 On the other hand, I find it quite complicated, if I tried to create a Data(String dbLocation) instance in ConfigurationGUIController, just to see if loading the database file works here.

==> Don't do such thing, it screams poor design (loading the object just to see if its loads correctly, and then loading it for real later.. I advise not to consider such thing)


1.5 If I do not verify the given database location in the configuration gui panel before, I seem to run into the problem, how to handle the possibly upcoming errors while staying in the init() method (I also do not want to catch and loop).

==> My user GUI (FileChooser) would not let me go through until the "Business" method would not successfully run (meaning, it successfully loaded the database, did not raise exception...)


2.1 Would it be the better way to call the configuration GUI in ServerImpl.init() but to let the GUI stay as long as the server is running (making a shutdown with button possible too)?
This would mean that the ConfigurationGUIController (inside ServerImpl) listens for the "Start"-ActionEvent and calls ServerImpl.execute() itself.
Wouldn't it be then the only requirement to move my call "new MyRMIRemoteDatabaseImpl(dbLocationPath)" from ServerImpl.init() to execute(), catching appropriate exceptions and letting the user to re-try to hit "Start" again?

==> Obviously, I don't know all the operations you're doing in ServerImpl.init(). Try to load your Server GUI first. After that, get the input from the user while trying to load the database. If the database is not correct, you only need to get the input from the user again, your Server GUI should not be crashing..

Even if you try to start your server at launch time, when you try to connect to the database, your server GUI should be stable enough not to crash if a wrong file is selected.

Ex:
1. main() -> build GUI (which includes a Browse for database file)
2. User action select database file -> GUIListener -> controller.selectDB() -> ServerImpl.init() -> LoadDB ** crash

Your GUIListener or Controller should catch some Exception and figure out how to modify the GUI accordingly.

I Hope this helps

Regards,
Alex
[ February 22, 2008: Message edited by: Alex Belisle Turcot ]
 
Consider Paul's rocket mass heater.
 
subject: B&S ConfigurationGUI DB location process/errorhandling in init