Monday, October 26, 2009

Struts 1.3.10 on Tomcat 6 Tutorial

I started working through Hightower's tutorial available as a free pdf from theserverside.com and am having a few problems. I will record fixes as I encounter problems. Note that Struts version 1.3.10 has changes whereas the Hightower tutorial, Jakarta-Struts Live, is for version 1.1. I am also working with Tomcat 6 (apache-tomcat-6.0.18) , ant (apache-ant-1.7.1) and Java 6 (jdk1.6.0_04) . The fixes I am describing are what I am getting to work on the above-described configuration. I am not saying that the tutorial is wrong for Struts version 1.1.

--------------
CHAPTER 1
--------------

On page 4 where he is discussing setting up on a Tomcat 5 server, note that Tomcat 6 has changed the previous directory structure $TOMCAT_HOME/common/lib/ to just $TOMCAT_HOME/lib/ ... there is no longer a common directory present.

On page 17 where we are writing our first action form, note that the class ActionError is no longer available in Struts 1.3.10 and one must use ActionMessage instead. So, in the code for the UserRegistrationForm class, comment out 'import org.apache.struts.action.ActionError;' and add 'import org.apache.struts.action.ActionMessage;' ... Also later on, swap out ActionError in the validate method with ActionMessage.
On page 20 where we are writing our first input view (jsp page), we ignore any of the changes to the web.xml file with regard to the additions. Also, still in #2 on that page, we do the directives in the jsp differently. Instead of
'<%@ taglib uri="/tags/struts-html" prefix="html"%>'
use the following namespaces for the uri, like this:
'<%@ taglib uri="http://struts.apache.org/tags-html" prefix="html"%>'
'<%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean"%>'
I spent a lot of time diddling around with this and from what I read in the google searches, a lot of other people have wasted time too. This is because the tld's are packaged in the struts-taglib-1.3.10.jar file which is in the lib directory in WEB-INF in the struts-blank app. The servlet api has now made it easy to find the tlds in the jar file provided they were packaged properly (see the Struts site for instructions for a proper configuration or look at the jar file in the distribution). Note that including taglib information in web.xml will result in the application not being able to find the tlds.

_________________________________________________________________
ON PAGE 27 UPDATE THE ACTION TO HANDLE FORM AND CANCEL BUTTONS
Since version 1.2.8 the 'cancellable="true"' statement must be placed in the action tag path="/userRegistration" in struts-config.xml. Otherwise, hitting the cancel button results in exception.

________________________________________________________________
MOVING ON TO USING DATABASE
As an FYI Hightower notes that, although he is using an HSQL database, "You
should be able to use any database that has a suitable JDBC driver." ... which should be true but in this example, the name of the table, USER, isn't going to work on an Oracle database because USER is a reserved word. Hence I changed the name of the table to STRUTSUSER since I was using an Oracle database.

On page 30 of the tutorial the code uses the method getDataSource which is not present on the Action class in version 1.3.10. I found a discussion at JavaRanch and will use a DAO which in turn will use JDBC to get a connection to the database. This is good for separation of concerns and is immediately valuable for unit testing the DAO independent of the rest of the application (always a good thing!). Nevetheless, this makes the datasource-relevant information, which was added to struts-config.xml, irrelevant and for me the entire Struts 1.X version somewhat dysfunctional and even more reason to use Struts 2.x version or, its evolved form (Spring... :). Having just coded the DAO and using raw JDBC for database manipulation, I am reminded of how easy Spring makes database manipulations because it saves you from TCFTC (Try-Catch-Finally-Try-Catch).

Oh, and yes, at this point forget about letting Struts handle any database connection pooling ...
________________________________________________________________
PAGE 32: EXCEPTION HANDLING
Now that we're not even using Struts to manage database connections, it's not going to see any sql exceptions either(we're catching sql exceptions in our DAO) so we need to find another way to worry about exception handling by Struts.

________________________________________________________________
PAGE 35: DISPLAY AN OBJECT WITH STRUTS TAGS

This works as described in the tutorial but remember to use the uri discussed above for the bean tag.

________________________________________________________________
PAGE 37: USING LOGIC TAGS TO ITERATE OVER USERS

As discussed above, the logic tags directive would look like this:
<%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic"%>

--------------------------------------
CHAPTER 2: TESTING STRUTS
--------------------------------------

Having suffered through the early versions of EJB I am reminded of one of the reasons why developers created their own lightweight frameworks, like Struts and Spring - to enable unit testing the POJOs (the domain-object model) without the container obstructing the tests. For those not familiar with the history of that era, I recommend Bruce Tate's "Don't Make Me Eat The Elephant Again."
________________________________________________________________
PAGE 59: Using StrutsTestCase (Mock Mode) Step-by-Step

I will be using strutstest-2.1.4.jar



Sunday, October 4, 2009

KISS & Object-Oriented Programming

This piece examines the response to decentralizing reponsibility from the KISS (Keep It Simple Stupid) perspective. Decentralizing responsibility generally creates more objects and upon first examination most programmers fail to understand the advantage. This is because their education generally involved the solution of problems that rewarded their ability to create small cute programs and not the solution of problems rewarding their ability to create coherent and loosely-coupled classes containing methods responsible for doing only one thing. Upon refactoring their solutions to systems containing more objects, the typical response is to question how this leads to a simpler system. Their education did not prepare them for creating complex software systems composed of harmoniously working objects. Their education layed the groundwork for creating hopelessly complex, difficult to maintain and impossible to change nightmares commonly referred to as "Big Balls of Mud" [1]. Being an object-oriented programmer is more than incorporating byzantine thinking into a program running with an object-oriented language. A true object-oriented programmer knows how to think on a higher level. A level that is amenable to building much larger systems that are easy to maintain and change.

REFERENCES

1. The Big Ball of Mud paper is in my opinion a must read for anyone interested in enterprise-level software creation. This paper reveals the sticky problems of integrating the ideals of software creation with the reality of the contemporary corporate IT workplace.

Thursday, October 1, 2009

Moneyware: Comparing baseball and computer science cultures

"I think, really, that this is one reason that so many intelligent people drift away from baseball (when they come of age), that if you care about it at all you have to realize, as soon as you acquire a taste for independent thought, that a great portion of the sport's traditional knowledge is ridiculous hokum."
... Bill James

"It is not the task of the University to offer what society asks for, but to give what society needs."
.... Edsgar Dijkstra

My sons have prompted me to read Moneyball by Michael Lewis. Anyone interested in baseball should find this a fascinating read. While contemplating Moneyball I found myself making comparisons between baseball and software development. The book tells the story of Bill James who began to statistically analyze baseball data and his results showed that there were skills that weren't recognized as having appropriate value. Value is considered in terms of what wins baseball games, contributions to runs. His efforts to convince the baseball establishment were met with stiff resistance. His message, although statistically sound and rational, was not synchronous with an irrational and stubborn baseball culture. I wondered whether the baseball phenomenon was similar to the resistance of the academic computer science culture to incorporate new proven methods, such as unit testing, into fundamental programming courses. This "we don't need no stinkin tests" culture leads to the creation of professionals who haven't been taught a very valuable skill that is sorely needed in the contemporary IT work place. A parallel example in baseball is that as youngsters, baseball players are not taught to be more selective about which pitches they swing at. Just as it has been shown that on base percentage is a more meaningful (in terms of contribution to runs) statistic than the batting average, we still announce a player's batting average when watching a televised baseball game. When was the last time you heard a baseball announcer tell the player's on-base percentage? We are a culture paying attention to statistics that focus on a less important aspect of the game. In software development, although it has been shown numerous times that unit-tested software increases ROI, our industry still suffers from >50% failure rates in large IT projects. Nevertheless, just as in baseball, we continue to go about these projects in the way the culture dictates instead of following proven practices. Even worse, we educate future programmers the same way we did fifty years ago. Isn't it time to re-evaluate how we are educating our future software developers?

Moneyball describes the development of the science of baseball to the point where people began to analyze the game from the perspective of derivatives in the stock market. However, to accomplish this, a better system was needed to analyze baseball events. For example, when a person hits a double in baseball, there are so many factors in play, that from an analytical perspective the term 'double' did not contribute enough information. An entirely new system was designed to analyze the events in baseball. The same is needed in software systems development and in the educational process at the undergraduate level.