Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment:

Update nomenclature and formatting
Wiki Markup


h2. Preface

Struts Action Framework 2 is a popular, 

Preface

...

easy-to-use MVC framework.

...

 For more information on the

...

 SAF project, please visit the

...

 [SAF Project Home|SAF2].

...


This document will help you to get started with

...

 the framework, enabling you to run the examples and demonstrations provided even if you are not an experienced Java web application developer. Nevertheless,

...

 the framework is geared towards developers that have an understanding towards certain technologies. 

Before diving deeper into how

...

 the SAF works, it is recommended that

...

  • Java
  • Servlets, JSP, and Tag Libraries
  • JavaBeans
  • HTML and HTTP
  • Web Containers (ex. Tomcat)
  • XML

...

Download Webwork Distribution

You can download the full WebWork distribution here. It contains the webwork.jar file as well as full documentation, sources, all required and optional dependent libraries,and examples. For more information on how to build WebWork from source or even from a clean CVS checkout, please refer to Building Webwork.

Online Information and Project Resources

There are many online sources of information, support and project resources around. Here are links to help you find your way:

Distribution Quickstart

Overview

The distribution contains the following directory layout:

No Format

dist/
docs/
lib/
src/
src/java/template/
webapps/
README.txt
build.properties
build.xml
ivy.xml
osbuild.xml
pom.xml
webwork-(VERSION).jar
webwork-(VERSION).zip
webwork-(VERSION)-src.jar

 

The docs directory contains the current Javadocs, the full user documentation including the document you are reading, and taglib documentation, as well as Clover, JUnit and dependency reports for the build.

The dist directory contains WebWork files with different packaging:

  • webwork-nostatic-<version>.jar: containing only WebWork without the static content
  • webwork-static-<version>.zip: containing the required WebWork static dependencies

The lib directory contains the required as well as optional Dependencies for Webwork, organized in subdirectories to represent different optional configurations:

No Format

lib/
      ajax
      bootstrap
      build
      cewolf
      default
      fileupload
      fileupload-cos
      fileupload-pell
      hibernate
      jasperreports
      jfree
      pico
      plexus
      portlet
      quickstart
      sitemesh
      source
      spring
      tiger
      tiles
      velocity
      xslt

 

Note that none of the optional packages are required to use Webwork. If you wish to use certain features such as JasperReports or Java 5 (Tiger) generics and annotation support, you must include the optional packages.

Webwork also comes packaged with all the source files and templates for the JSP tags.

...

WebWork provides a quick way to get started called QuickStart. QuickStart is essentially a combination of a few technologies, including the possibility to run web applications such as the provided examples out of the box with a stripped Jetty container.

With that, running the demos is as easy as can be. You just need to call:

Code Block

java -jar webwork.jar quickstart:<application-name>

 

from the distribution's top directory, whereby <application-name> is to be replaced by one of the subdirectory names under webapps/, representing the various supplied demo applications. So if you want to start the shopping cart example, just type on your command line:

Code Block

java -jar webwork.jar quickstart:shopping-cart

 

After starting an example in that way, you will simply need to point your browser to http://localhost:8080/shopping-cart to view the results.

The packaged examples are:

blank

Not really an example, but a blank web application template for creating your own application

portlet

Demonstration of WebWork porlet integration (to be deployed in a Portal Server) - see Portlet Tutorial to read more about that

shopping-cart

Nice example application demonstrating various aspects of WebWork

showcase

Demonstration of all tag and AJAX features, along with other examples and some best practices

starter

Basic web application, meant as an easy starting point for experimenting with WebWork's features - one could call it "playground"

Read Quickstart documentation to learn more about how it works and how you can utilize it for your own applications.

See below for a more detailed description of how the blank application helps you to easily create your own WebWork-based applications.

...

Note
titleTo Quickstart or not to Quickstart?

The previous section described the Quickstart mechanism for trying the supplied example webapps, but Quickstart is also a handy tool for development of your own WebWork based applications. We recommend you using the said mechanism unless you are familiar with standalone servlet containers and have good reasons to switch, such as preparing a production system etc.

 

In order to deploy WebWork applications and demos to your favorite servlet container (also called web container) such as Apache Tomcat or Caucho Resin, you will need to build war files from within the webapps directory. You will find an ant build file there which will provide you with an easy way to accomplish that.

To build a webapp war archive, simply run:

Code Block

ant build -Dwebapp=XXX

 

where XXX is the name of the webapp you want to build. After the build is finished, the fully-built war file can be found in the dist directory. You may deploy this file to any servlet container.

For example:
ant build -Dwebapp=showcase
To deploy the built showcase.war to Tomcat, just place it into <TOMCAT_HOME>/webapps/ or use the Tomcat Manager Application to upload and deploy the war. After the war is deployed (and your server is started), point your browser to
http://SERVER:PORT/APPLICATIONNAME, according to your setup and the application you deployed.

...

Using the Blank Template

As said before, the webapps directory contains a blank web application template. It is meant to be left untouched, and instead, you will want to make a copy of it as a starting point for your own new WebWork-based application. Although you can perform such a copy operation yourself, there is a much easier way around: You will find an build.xml in the webapps directory, which if called with ant new will provide you with a fresh empty webapp with a name you will be prompted for.

Setting up from Scratch

Structure of your Web Application

The following illustrates how your web application should be set up. Copy the webwork-(VERSION).jar, all the *.jar files in /lib/default and any necessary optional *.jar files in /lib/(optional configuration) to your webapp/lib directory. If you need to customize your own templates (how HTML is rendered from webwork UI tags), copy the /src/java/template directory into your webapp/ directory. Your webapp should look similar to this:

Code Block
 you have some knowledge of the supporting technologies.

{panel:title=Supporting Technologies}
- Java
- Servlets, JSP, and Tag Libraries
- JavaBeans
- HTML and HTTP
- Web Containers (such as Tomcat)
- XML
{panel}

For more about any of the supporting technologies, visit the [Key Technologies page|http://struts.apache.org/struts-action/userGuide/preface.html] on the Apache Struts website.

h2. Downloads and Resources {anchor:Website&downloads}

To get started with the framework, download the distribution and browse some of the online resources.

h3. Download the Distribution

{note}A release of SAF 2 may not yet be available.{note}

The full distribution can be downloaded form the [Apache Struts website|http://struts.apache.org/downloads.html]. The distribution contains the {{struts-action2.jar}} file, a copy of all the documentation, sources, all [required and optional dependencies|Dependencies],and example applications. For more information on how to build the framework from source or even from a clean checkout, please refer to [Building the Framework from Source].

h2. Browse the Resources

There are many online resources available. Here are links to help you find your way:
- [Download SAF2|http://struts.apache.org/downloads.html] \- download the framework distribution
- [Join the Forums|http://forums.opensymphony.com/category.jspa?categoryID=5] \- The forums are full of active developers, contributors, and power users - often even available for chat. This is the best and quickest way to get a question answered.
- [Subscribe to Mailing List and post a question, or browse Mail Archive|http://struts.apache.org/mail.html]. (You probably want to browse the archive or forum first. All posts from the forum are posted to the mailing lists, and vice versa.
- [Subversion Repository|http://svn.apache.org/viewcvs.cgi/struts/action2/] \- Browse the source.
- [Confluence Wiki|http://confluence.twdata.org/] \- Read it here first! The project documentation is created on the wiki and then posted as HTML to the website. 
- [JIRA Issue Tracker|http://issues.apache.org/struts/] \- Browse or file enhancements requests and defect reports.
- [Apache Struts Home|http://struts.apache.org/]

h2. Distribution Quickstart


h3. Overview

The distribution contains the following directory layout:
{noformat}
dist/
docs/
lib/
src/
src/java/template/
webapps/
README.txt
build.properties
build.xml
ivy.xml
osbuild.xml
pom.xml
struts-action-(VERSION).jar
struts-action-(VERSION).zip
struts-action-(VERSION)-src.jar
{noformat}
The {{docs}} directory contains the current Javadocs, the full user documentation including the document you are reading, and taglib documentation, as well as Clover, JUnit and dependency reports for the build.

The {{dist}} directory contains framework files with different packaging:
- struts-action-nostatic-<version>.jar: containing only the framework without the static content
- struts-action-static-<version>.zip: containing the required framework static dependencies

The {{lib}} directory contains the required as well as optional [Dependencies] for the framework, organized in subdirectories to represent different optional configurations:
{noformat}
lib/
      ajax
      bootstrap
      build
      cewolf
      default
      fileupload
      fileupload-cos
      fileupload-pell
      hibernate
      jasperreports
      jfree
      pico
      plexus
      portlet
      quickstart
      sitemesh
      source
      spring
      tiger
      tiles
      velocity
      xslt
{noformat}
Note that none of the _optional_ packages are required to use the framework. If you wish to use certain features such as JasperReports or Java 5 (Tiger) generics and annotation support, then you must include the optional packages.

The framework also comes packaged with all the source files and templates for the JSP tags.

h2. Running demos with QuickStart{anchor:Running demos}

The framework provides a slick way to jump into web development called QuickStart. Essentally, QuickStart is combination of technologies and conventions. The key technology is the ability to run web applications "out of the box" with a stripped-down [Jetty|http://jetty.mortbay.org/jetty/] container.

With QuickStart, running the demos is as easy as can be. You just need to run:
{code}
> java -jar webwork.jar quickstart:<application-name>
{code}
from the distribution's top directory, where {{<application-name>}} is one of the subdirectory names under {{webapps/}}. Each subdirectoy hosts a demo application. 

If you want to start the shopping-cart webapp, the startup command would be:
{code}
> java -jar webwork.jar quickstart:shopping-cart
{code}
One the application starts up, point your browser to {{[http://localhost:8080/shopping-cart/]}}, and you should be ready to go. 

Several example appliations are included in the distribution. 
|| blank | Not really an example application, but a _blank_ web application template to use as the base for your own applications |
|| cookbook | A "how to" application that displays the full source code for each "recipe". |
|| mailreader | The infamous Struts MailReader application.
|| portlet | Demonstration of our porlet integration (to be deployed in a Portal Server) - see [Portlet Tutorial] to read more about portlets |
|| shopping-cart | Simple example application demonstrating various aspects of the framework |
|| showcase | Extensive demonstration of all tag and AJAX features, along with other examples and some best practices |
|| starter | Basic web application that you can use as a starting point for experimenting with framework features - one could almost call it a "playground" application |

You can review the [QuickStart documentation|QuickStart] to learn more about how it works and how you can utilize QuickStart with your own applications.

See below for a more detailed description of how the blank application helps you to easily create your own WebWork-based applications.

h2. Running Demos with Your Favorite Web Container {anchor:Running demos}

In order to deploy applications and demos to your favorite servlet container (also called web container) such as [Apache Tomcat|http://jakarta.apache.org/tomcat/] or [Caucho Resin|http://www.caucho.com/], you will need to build WAR files from the webapps directory. You will find an Antbuild file there which will provide you with an easy way to build your own WARs.

{note:title=To Quickstart or not to Quickstart?}
Quickstart is a handy tool for development of your applications. We recommend that you give QuickStart a try, to see if it meets your development needs. However, QuickStart is not meant to be your sole environment for web application development. QuickStart is meant to help you rapidily create proof-of-concepts and so that you can see the result. We recommend you always at least test your work under other applications servers, such as Tomcat, Resin, or even the standard, standalone version of Jetty.
{note}

To build a web application archive (WAR), simply run:
{code}
> ant build -Dwebapp=$APP
{code}
where {{$APP}} is the name of the web application you want to build. After the build is finished, the fully-built WAR file can be found in the {{dist}} directory. You may deploy this file to any servlet container.

To build the {{showcase}] aplication, substite "showcase" for $ID.

{code}
> ant build -Dwebapp=showcase
{code}

To deploy the built {{showcase.war}} to Tomcat, move or copy the WAR to {{$TOMCAT_HOME/webapps/}} or use the Tomcat Manager Application to upload and deploy the WAR. After the WAR is deployed (and your server is started), point your browser to 

{code}
> http://localhost/showcase
{code}

Of course, if the server is not local, substitute the IP or hostname for "localhost", including a port designation if needed.  If you are not deploying the Showcase application, then substitute the appropriate application name for "showcase"

{info:title=Deploying the Examples}
The framework build copies the sources of each bundled web application to {{dist/webapps/$APP}}. The build also compiles the sources for each appolication and creates a WAR at {{dist/webapps/$APP.war}}. However, these WAR files are NOT ready to be deployed. These WARs do not include any of the JAR files. (Omitting the JARS reduces the size of the download by almost 200mb.) To include the dependant JARs, run Ant in the {{dist/webapps}} directory, and new WARs, with all the JARs, are placed in {{dist/webapps/dist}}.
{info}

h2. Your First SAF2 Application {anchor:Installing}

To get started on your own application, you can utilize the blank template, run the Ant task, or just setup your own from scratch.

h3. Using the Blank template

The blank web application in the distribution's {webapp} directory is meant as a template. Make a copy of "blank" and use the copy as the basis for your application. 

h3. Run the Ant task

While it's simple enough to copy a directory tree, there is an even easier way to get started. In the {{webapps}} directory, there is a {{build.xml}} file. The {{new}} task of this Ant build file can create fresh, empty web application for you. Just add content! 

{code}
> cd /projects/Apache/struts-current/action2/webapps
> ant new
{code}

The Ant buildfile will prompt you for a the name of your new application.

h3. Setting up from Scratch

If for some reason the blank template doesn't work for you, it's not so hard to setup a SAF-based application from scratch.

h4. Structure of your web application

* Setup a file structure for your application. 

{code}
/mywebapp/
/mywebapp/template/
/mywebapp/META-INF/
/mywebapp/WEB-INF/
/mywebapp/WEB-INF/classes/
/mywebapp/WEB-INF/lib/
/mywebapp/WEB-INF/lib/CORE&OPTIONAL *.jar
/mywebapp/WEB-INF/web.xml

 

Minimum Set of Libraries and Config Files

The following files are a minium requirement for your application.

Filename

Description

webwork.jar

WebWork library itself, found in distribution root directory

xwork.jar

XWork library on which WebWork is built

oscore.jar

OSCore, a general-utility library from OpenSymphony

ognl.jar

Object Graph Navigation Language (OGNL), the expression language used
throughout WebWork

commons-logging.jar

Commons logging, which WebWork uses to support transparently logging to
either Log4J or JDK 1.4+

freemarker.jar

All UI tag templates are written in Freemarker, which is also a good option for your views

rife-continuations by rife

for the continuations feature

web.xml

J2EE web application configuration file that defines the servlets, JSP tag
libraries, and so on for your web application

xwork.xml

WebWork configuration file that defines the actions, results, and interceptors
for your application

The library files (*.jar) needs to be copied to your /mywebapp/WEB-INF/lib/ directory. If you need optional functionalities requiring dependencies on optional jars, they need to be copied to this directory, too.

Note
titleSpring as default IoC Container

Before WebWork 2.2, the builtin Dependency Injection (IoC) container was default. Since Spring has been found to do this job better, the container integrated in WebWork / XWork was deprecated. If you would like to follow our recommendation to use Spring as the default IoC container, please make sure to include all jars found in lib/spring in the WEB-INF/lib directory of your application.

 

 

web.xml:

Wiki Markup
Create the following {{web.xml}} file in {{\[webapp\]/WEB-INF}}. If you already have a {{web.xml}} file, just add the content of the <web-app> tag below to your existing <web-app> tag.

...


<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
  <display-name>My WebWork Application</display-name>
  <filter>
    <filter-name>webwork</filter-name>
    <filter-class>com.opensymphony.webwork.dispatcher.FilterDispatcher</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>webwork</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <!-- As of 2.2, Spring is the preferred IoC container rather than XWork,
       so you'll have to include the spring jars if you want to use
       Spring's IoC capabilities in WebWork. (Thanks Hani for commenting)
       If you want to use deprecated integrated IoC container instead, you may
       want to omit the following listener configuration.
  -->
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

  <!-- The following taglib directive would be needed if your servlet container would comply
       to Servlet Spec <= 2.2
  <taglib>
    <taglib-uri>/webwork</taglib-uri>
    <taglib-location>/WEB-INF/lib/webwork.jar</taglib-location>
  </taglib>
  -->
</web-app>

 

This registers FilterDispatcher to enable webwork functionality for your requests. The ContextLoaderListener will take care of setting up Spring as your IoC container for WebWork. The taglib entry will help you use Tags in your JSP pages.

Read more: web.xml

xwork.xml:

...

 *.jar
/mywebapp/WEB-INF/web.xml
{code}

* Copy to your {{webapp/lib}} directory 
** the {{struts-action-(VERSION).jar}}, 
** all the {{\*.jar}} files in {{/lib/default}}, 
** and any necessary optional {{\*.jar} files in {{/lib/_(optional configuration)_ }}. 

(/) If you need to customize your own templates (how HTML is rendered from webwork UI tags), copy into your {{webapp/}} directory the {{/src/java/template}} directory.  

h4. Minimum Set of Libraries and Config Files

The following files are a minium requirement for your application.

|| Filename || Description ||
|| struts-action.jar | Framework library itself, found in distribution root directory |
|| xwork.jar | XWork library on which WebWork is built |
|| oscore.jar | OSCore, a general-utility library from OpenSymphony |
|| ognl.jar | Object Graph Navigation Language (OGNL), the expression language used throughout the framework |
|| commons-logging.jar | Commons logging, which WebWork uses to support transparently logging to either Log4J or JDK 1.4\+ |
|| freemarker.jar | All UI tag templates are written in Freemarker, which is also a good option for your views |
|| spring*.jar | The default dependency injection container for the framework.  |
|| web.xml | J2EE web application configuration file that defines the servlets, JSP tag \\
 libraries, and so on for your web application |
|| action.xml | WebWork configuration file that defines the actions, results, and interceptors for your application |

The library files ({{*.jar}}) needs to be copied to your {{/mywebapp/WEB-INF/lib/}} directory. If you need optional functionalities requiring dependencies on optional JARs, those JARs need to be copied to this directory too.

h4. {{web.xml}}

Create an {{web.xml}} file in {{\[webapp\]/WEB-INF}} (or merge into it the framework resources).

{code:title=web.xml}
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
  <display-name>My Application</display-name>
  <filter>
    <filter-name>action2</filter-name>
    <filter-class>org.apache.struts.action2.dispatcher.FilterDispatcher</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>action</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
</web-app>
{code}

The standard{{web.xml} registers {{FilterDispatcher}} to enable framework functionality for your requests. The ContextLoaderListener set ups [Spring] as our dependency injection conitainer. The framework uses Spring internally, and you may wish to use it to deploy your own objects. 

(on) See also: [web.xml]

h4. {{action.xml}}

Create a skeleton {[action.xml}} file in {{/$APP/WEB-INF/classes/}}.

...

Code Block
xmlxml


{code:title=action.xml}
<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.1.1//EN"
"http://www.opensymphony.com/xwork/xwork-1.1.1.dtd">

<xwork>
	<!-- Include webworkframework defaults (from Struts WebWorkAction JAR). -->
	<include file="webworkaction-default.xml" />

	<!-- Configuration for the default package. -->
	<package name="default" extends="webworkaction-default">
	</package>
</xwork>

 

For now, this xwork.xml does only two things:

  • It informs WebWork that it should import the configuration information from webwork-default.xml. (This file is located at the root of the webwork.jar, so it is sure to be found.)
  • It defines a default package (with the <package> section) where WebWork elements like actions, results and interceptors are registered.

Read more: action.xml

...


{code}
For now, the {{action.xml}} does only two things:

* It tells the framework that it should import the configuration information from {{action-default.xml}}. (This file is located at the root of the {{struts-action.jar}}, so it is sure to be found.)

* It defines a default package (with the <package> section) where framework elements like {{actions}}, {{results}} and {{interceptors}} are registered.

(on) See also: [action.xml]

||Next | Onward to the [First lesson|Basic configuration and your first action - Hello WebWorld] |
||Prev | [Return to the tutorial start page|SAF2]