Java technologies give developers a serious boost when creating and maintaining applications to meet the demands of today's public Web sites and enterprise intranets. Struts Action Framework combines standard Java technologies into a unified framework. The end result is a cooperative, synergistic framework, suitable for development teams, independent developers, and everyone in between.

Java Servlets are designed to handle requests made by Web browsers. Server pages are designed to create dynamic Web pages that can turn billboard sites into live applications. Struts Action Framework uses a special Servlet as a switchboard to route requests from Web browsers to the appropriate server page. This makes Web applications much easier to design, create, and maintain.

Yes. Struts is committed to supporting industry standards. Struts acts as an integrator of Java technologies so that they can be used in the "real world".

There are several active committers to the Apache Struts project, working cooperatively from around the globe. Dozens of individual developers and committers contributed to the Struts 1.x codebase. All interested developers and wordsmiths are invited to contribute to the project .

The initial Struts codebase (Struts 0.5) was created by Craig R. McClanahan in May 2000 and donated to The Apache Software Foundation in May 2000. Craig was the primary developer of both Struts 1.x and Tomcat 4 . Tomcat 4 was the basis for the official reference implementation for a servlet 2.3 and JSP 1.2 container.

After serving as the co-lead of the JSR 127 specification (JavaServerFaces), Craig created another rendition of Struts based on JavaServerFaces, called Shale. Both Struts Action Framework and Struts Shale are first-class citizens of the Apache Struts project.

No, not by a long shot. When Struts 1.0 shipped in June 2001, there were already several other web application frameworks available, including Barracuda, Expresso, Maverick, Tapestry, and Turbine, to name a few. Struts did not enter a "greenfield". Back in the day, there were lively comparisons between the available frameworks, just as there is today.

Yes. By any objective measure, Struts Action continues to be the most popular web application framework for Java.

As of 2006, the vast majority of job offerings for Java developers cite Struts as prerequisite. According to OnJava magazine between their reader surveys for 2005 and 2004 the popularity of Struts remained steady. Likewise, the number of Struts articles published in all online journals also remained constant between 2004 and 2005. New and updated books about Struts continue to be published regularly.

While some people characterize the space of Java web application framework as being "fragmented", the truth is that more web developers use Struts Action than all other alternatives combined. This observation is as true in 2006 as it was in 2005, as it was in 2004. It's probably been true since Struts released its 1.0 version in 2001.

Of course, some developers are finding that JavaServer Faces can be a faster way to write new applications, especially clean-cut intranet applications. And that's great! More than anything else, every Struts committer wants every developer to get more out of every work day. (We're developers too!) As these new JSF applications grow in complexity, Struts Shale is ready to do for JSF developers what Struts Action has been doing for JSP developers, year after year after year.

Meanwhile, enterprise web developers who have standardized on Struts Action can be assured that new releases of Action 1 will continue, even as we break new ground with the upcoming release of Struts Action 2 (formerly known as WebWork).

The best place to download Apache Struts products is at struts.apache.org . The nightly builds are very stable, and recommended as the best place to start today.

To develop applications with Struts, you can usually just add the Struts JAR file to your Java development environment. You can then start using the Struts classes as part of your own application. A blank Struts application (in the webapps directory, open struts-blank.war ) is provided, which you can just copy to get a quick-start on your own brainchild.

Aside from the Struts Action Framework jar, the blank application includes the other Struts Action Framework Library JARs and dependencies. All dependencies are compatible with the Apache License.

Since the full source code for Struts is available, we also provide complete instructions for compiling your own Struts JAR from scratch. (This is actually easier than it looks!)

Your Struts application can usually be deployed using a standard WAR file. In most cases, you simply deposit the WAR file on your application server, and it is installed automatically. If not, step-by-step installation instructions for various servlet containers are available.

When you are compiling an application that uses the Struts classes, you must have the "struts-action.jar" on the classpath your compiler sees -- it does not have to be on your CLASSPATH environment variable.

Why is that an important distinction? Because if you are using a servlet container on your development machine to test your application, the "struts-action.jar" must not be on your CLASSPATH environment variable when running the container. (This is because each Web application must also have their own copy of the Struts classes, and the container will become confused if it is on the environment path as well.)

There are several general approaches to this issue:

• Use ANT for building your projects -- it can easily assemble classpaths for the compiler. (This is how Struts itself is built, along with Tomcat and most other Java-based projects).
• Use an IDE where you can configure the "class path" used for compilation independent of the CLASSPATH environment variable.
• Use a shell script that temporarily adds struts-action.jar to the classpath just for compilation, for example
  javac -classpath /path/to/struts-action.jar:$CLASSPATH $@

Struts Action Framework currently has two testing environments, to reflect the fact that some things can be tested statically, and some really need to be done in the environment of a running servlet container.

For static unit tests, we use the JUnit framework . The sources for these tests are in the "src/test" hierarchy in the source repository, and are executed via the "test.junit" target in the top-level build.xml file. Such tests are focused on the low-level functionality of individual methods, are particularly suitable for the static methods in the org.apache.struts.util utility classes. In the test hierarchy, there are also some "mock object" classes (in the org.apache.struts.mock package) so that you can package up things that look like servlet API and Struts API objects to pass in as arguments to such tests.

Another valuable tool is Struts TestCase which provides a useful harness for Action classes that can be used with JUnit or Cactus .