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

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.

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.

Mr. President - Stand down

Upon reflection, I modified my original post by inserting the following quote from Nietzsche.

"He who fights with monsters should look to it that he himself does not become a monster. And when you gaze long into an abyss, the abyss also gazes into you."

Dear Mr. President:

I'm disheartened to hear statements regarding whether your administration will seek to prosecute former Bush administration officials for breaking our laws regarding torture. What happened to our beliefs in law as a process? We have institutions that investigate these matters so why not let them do their jobs? Isn't that why Gonzalez was discredited - following the wishes of the Bush administration? Let's hope our current justice department isn't waiting for you to make the call Mr. President. Please, stand down and let them do their jobs and permit us to believe you aren't calling all the justice department moves.

Respectfully but in doubt,

Doktat

Open Source Software vs. Caveat Emptor

One of the common arguments for proprietary software is that there is some kind of permanence in having a corporate entity backing the product you have invested in. To counter this I tell the following story. When Java first appeared in the mid-90's I was very eager to learn it and invested in a Java IDE from Symantec called Visual Cafe. It was a good product and won a best tool of the year award , a CNET Excellence award for Internet tools and many other accolades. Things were good and I was learning Java and paying handsomely to keep up with the Visual Cafe updates. Yes, I was thriving in the throes of capitalism and proprietary software ... and then it was gone.

No, Symantec didn't go out of business. They sold the product line to BEA and BEA did nothing with it but put it away - my investment meant nothing (caveat emptor). What remains of my investment is an unsupported product that is out of date and useless. My graduate research mentor used to say, "Don't descend into the well on a frayed rope." In my mind proprietary software is a frayed rope. Buying a software product should mean paying for access to code not a black box (I am reminded of Scott McNealy's question "Would you buy a car with the hood welded shut?"). Then, if the software company goes out of business, at least you have the code to do with as you please (except take it and sell it again). Better yet, go with an open source solution and use the money you saved to invest in a person who will know and understand how the software works or buy support from the people who wrote the software. Then there will never be a time when your software becomes useless due to bankruptcy or pricing. Beware of proprietary software, it is a short term solution with no future. Go with open source - no one can ever take it away from you.

Prompt Corrective Action Law (PCA): Off With Their Heads

Haven't seen the interview of William Black by Bill Moyers? Don't miss it - it's an eye opener and methinks something is terribly rotten in er ... ah, not Denmark, but dear old USA. Black's claims of fraud and implicit assumptions that we've been taken by the short term strategies of current corporations gone to extremes - ah, that is, crime - are scary. But even more frightening is the discussion of the PCA (Prompt Corrective Action) law and the fact that this law is not being enforced - a law that was intended to protect the taxpayers from failing banks.

Yes, I see reports of angry people in the USA but where is the action in the streets? We have been and are being screwed by the financial bourgeoisie in this country and we should be rioting. What has happened to the indignant riotous rabble that characterized those who founded this country? It appears that even Obama is held captive by the infamy. What is happening? We don't know and that is what Black is saying - it's a cover-up. Please don't tell me we need the executives, who ran us into this ditch, to get us out of it. If it's the law then the law should be enforced - particularly when the intent of the law was to protect us from what is happening right now - the looting of our citizens.

Time for a Paradigm Shift in Programming Pedagogy

### CODE ALA BUGS ###

A long-standing problem in software development is the detection and elimination of bugs. Numerous procedures such as Design by Contract , Cleanroom Software Engineering and Test-driven Development (TDD) are known to minimize bugs. Thus, one wonders why such practices are not used extensively in contemporary practices. Michael Feathers has recently noted that the common attribute among these practices was that they all required contemplation of the code’s purpose.

As an educator this lack of certainty regarding a programmer’s ability to write effective code triggers the question whether we are teaching programming courses appropriately.

### PEDAGOGICAL PRACTICES ###

Examination of current programming texts reveals the general approach to how programming courses are taught. This involves the reading, lecturing and discussion of the programming concept, studying code examples implementing the concept, and problem solving. The later generally requires the student to write a simple application involving the use of the above-mentioned concept or principle. The code correctness is easily determined because the application is simple. The application can be executed with a varying set of input data and the results determine the correctness of the code. This approach works adequately in such simplistic circumstances but fails when programming larger and complex software systems. Nevertheless the beginning programmer learns to depend on this quick method of verification during this important developmental stage.

### DENIAL AND INTERVENTION ###

The troubling aspect of this approach to teaching programming is the denial ensconced in the approach to the solution. The approach assumes the programmer will write code that will do what the programmer thinks it will do. The denial lies in the failure to recognize that the code often doesn’t do what it was written to do. In the words of Kent Beck
“I am good at fooling myself into believing that what I wrote is what I meant.”1
Even worse is the inability to alter behavior to compensate for this failure. Could contemporary computer science faculty be responsible for permitting this state of denial? Is it time for intervention?

### UNCERTAINTY IN PROGRAMMING ###

Programming students should learn about the uncertainty inherent in writing code; that all programmers, even excellent ones like Kent Beck, are susceptible to this uncertainty. Programming students should be taught that along with the recognition of the uncertainty implicit in the process of writing code, comes the realization that their solutions must be considered hypothetical. Hence, the validity of their hypothetical code solutions relies on how extensively the hypothesis has been tested. But wait! – isn’t this the scientific method every school kid learned in their K-12 years?

### PROGRAMMING AS SCIENTIFIC PROCESS ###

Considerable evidence exists that software creation is riddled with uncertainty and thus untested code represents at best a guess at a possible solution. Shouldn’t this be the fundamental principle taught to programming students? Why isn’t testing the validity of the hypothetical taught as the foundation of programming? In the face of the problems currently found in software development, why do we continue with a failed approach to programming pedagogy? Isn’t it time to confront the denial ensconced in the assumption that we can write code that will do what we intend? Hasn’t the time come to teach programming as a scientific process?

### SCIENCE & TDD ###

Test-driven development (TDD) defines a process whereby the programmer first writes a test which determines whether the intended function accomplishes its purpose. After the test is written, the function is then written to pass the test. Inherent in this procedure is the recognition that to truly understand the function one must understand how to test whether the function works as intended. This act is what Michael Feathers calls the contemplation of the code which is required to practice TDD along with other processes such as Design by Contract and Cleanroom Software Engineering. However, also implicitly assumed is the recognition that writing code is fraught with uncertainty and although the language of TDD is not that of the scientific method, the intent and the results are equivalent.

### REFERENCES ###
1. Beck, Kent (2000) Extreme Programming Explained: Embrace Change, Pearson Education, [ISBN 8178086670]