Reading this:
"// This abstract class overrides Struts action class execute method and provides abstract
// performAction method to be overwritten by sub-classes. This helps us isolate some
// common error processing into one place, rather than having it several places in the
// sub-classes."
I don't really see how handling the errror in the AbstraAction class simplify error handling the subclasses.
In errors.add("name", new ActionError("id")); the value & key pair are different from what we have in subclasses.

Hello,
Could you please tell me how this dbtest worked?
As I tried following the article but was lost when
it spoke of the different classes I did not know what these classes should contain and how they communicate with each other.
Thank you for your help

Hi,

I got an error trying to uncompress the .war file, it seems that it's broken.

SEVERE: Exception fixing docBase: {0}
java.util.zip.ZipException: error in opening zip file

Lucas.

Some users have complained about corrupted .war file.
Here is a link to the good one:
http://www.panix.com/~bm/DBTestSH.war

The war file is corrupted

I think the war file is corrupted. regards Mark

The provided DBTestSH.war is a corrupted one. You can not unzip it. Please check.
Thanks!

In the article 'Creating Web Applications with the Eclipse WTP' (http://jdj.sys-con.com/read/152270.htm ), we created a Web application using Eclipse Web Tools Project, the Tomcat application server, and the MySQL database server. That application (DBTest) was good, however, it had some limitations

While it was nice to see you bring all of these technologies together (Struts, XML, Java, Hibernate, WTP, MySQL and it's connector). One has to ask; "But why is this necessary?". This represents 7 technology related fail points and 7 tools that a programmer needs a good familiarity with to be efficiently productive. This is way too many! Each additional tool adds extra cost to evaluating programmers to staff business level Java client/server application development positions and increases project risk. While I love Java, as a manager, this is a huge problem with it's use.

What I'd like to see a lot more of is POJO solutions to serious Web application development problems.

While its great that you can bring all of these tools together to solve a problem, it does little to address the fundamental flaw with Java (and several other languages) which is... Java is not really designed for Server/dumb client applications (which are Web apps.) and after 10 years have been spent kludging it to fit that round hole... here we are still trying to make a square peg round.

If I'm wrong, I'd be thrilled to admit it. But to prove me wrong you have to build a true business level Web app. with just Java, an IDE, a database engine and its aplicable connector, and any vanilla Web server engine you choose. That's it. No XML, no cocoon, jscript, Struts, nada, zip. Oh, one final condition... development time has to be within 15% of development with all those "assists". If this can't be done, then let's all stop fooling ourselves, find something that does, and leave Java to solve the other problems it is designed for and stop trying to fit it into the wrong type of hole.

While it was nice to see you bring all of these technologies together (Struts, XML, Java, Hibernate, WTP, MySQL and it's connector). One has to ask; "But why is this necessary?". This represents 7 technology related fail points and 7 tools that a programmer needs a good familiarity with to be efficiently productive. This is way too many! Each additional tool adds extra cost to evaluating programmers to staff business level Java client/server application development positions and increases project risk. While I love Java, as a manager, this is a huge problem with it's use.

What I'd like to see a lot more of is POJO solutions to serious Web application development problems.

While its great that you can bring all of these tools together to solve a problem, it does little to address the fundamental flaw with Java (and several other languages) which is... Java is not really designed for Server/dumb client applications (which are Web apps.) and after 10 years have been spent kludging it to fit that round hole... here we are still trying to make a square peg round.

If I'm wrong, I'd be thrilled to admit it. But to prove me wrong you have to build a true business level Web app. with just Java, an IDE, a database engine and its aplicable connector, and any vanilla Web server engine you choose. That's it. No XML, no cocoon, jscript, Struts, nada, zip. Oh, one final condition... development time has to be within 15% of development with all those "assists". If this can't be done, then let's all stop fooling ourselves, find something that does, and leave Java to solve the other problems it is designed for and stop trying to fit it into the wrong type of hole.