Commits

Anonymous committed b4daa23

updated docs for 1.1 release

git-svn-id: http://svn.opensymphony.com/svn/xwork/trunk@740e221344d-f017-0410-9bd5-d282ab1896d7

Comments (0)

Files changed (73)

docs/wikidocs/Basics.html

+<html>
+    <head>
+        <title>XWork - 
+        Basics
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h2><a name="Basics-Actions">Actions</a></h2>
+
+<p>Actions are the basic unit of execution...</p>
+
+<h3><a name="Basics-TheActionInterface">The Action Interface</a></h3>
+
+<p>The basic interface which all XWork actions must implement. It provides several standard return values like SUCCESS and INPUT, and only contains one method:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-object">String</span> execute() <span class="code-keyword">throws</span> Exception;</pre>
+</div></div>
+
+<p>In general, Actions should simply extend ActionSupport, which provides a default implementation for the most common actions.</p>
+
+
+<h2><a name="Basics-ActionContext">ActionContext</a></h2>
+
+<p>The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment.</p>
+
+<p>The ActionContext is acquired through the static ActionContext.getContext() method. The ActionContext is a thread local variable and thus the properties of the ActionContext will be relative to the current request thread. The ActionContext has several methods for commonly used properties as well as get() and set() methods which can be used for application specific properties. </p>
+
+
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Building a Validator.html

+<html>
+    <head>
+        <title>XWork - 
+        Building a Validator
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>Validators implement the <b>com.opensymphony.xwork.validator.Validator</b> interface</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-keyword">interface</span> Validator {
+    void setDefaultMessage(<span class="code-object">String</span> message);
+
+    <span class="code-object">String</span> getDefaultMessage();
+
+    <span class="code-object">String</span> getMessage(<span class="code-object">Object</span> object);
+
+    void setMessageKey(<span class="code-object">String</span> key);
+
+    <span class="code-object">String</span> getMessageKey();
+
+    /**
+     * This method will be called before validate with a non-<span class="code-keyword">null</span> ValidatorContext.
+     * @param validatorContext
+     */
+    void setValidatorContext(ValidatorContext validatorContext);
+
+    ValidatorContext getValidatorContext();
+
+    /**
+     * The validation implementation must guarantee that setValidatorContext
+     * will be called with a non-<span class="code-keyword">null</span> ValidatorContext before validate is called.
+     * @param object
+     * @<span class="code-keyword">throws</span> ValidationException
+     */
+    void validate(<span class="code-object">Object</span> object) <span class="code-keyword">throws</span> ValidationException;
+}</pre>
+</div></div>
+
+<p>FieldValidators implement <b>com.opensymphony.xwork.validator.FieldValidator</b>, which extends Validator:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-keyword">interface</span> FieldValidator <span class="code-keyword">extends</span> Validator {
+
+    /**
+     * Sets the field name to validate with <span class="code-keyword">this</span> FieldValidator
+     * @param fieldName
+     */
+    void setFieldName(<span class="code-object">String</span> fieldName);
+
+    /**
+     * @<span class="code-keyword">return</span> the field name to be validated
+     */
+    <span class="code-object">String</span> getFieldName();
+}</pre>
+</div></div>
+
+<p>If you want to be able to use the "short-circuit" attribute, you should also implement <b>com.opensymphony.xwork.validator.ShortCircuitableValidator</b>.</p>
+
+<p>Validators and FieldValidators can extend base classes <b>com.opensymphony.xwork.validator.validators.ValidatorSupport</b> and <b>com.opensymphony.xwork.validator.validators.FieldValidatorSupport</b> to get the base message and short-circuiting behavior, and will only need to implement validate(Action action). </p>
+
+<p>The Support classes provide the functionality to use the message key and default message to get the localied message body and the parsing of the message body to provide for parameterized messages. Implementations of the Validator Interface which do not extend the Support base classes should provide this functionality as well for consistency.</p>
+
+<p>The <b>ValidatorContext</b> set into the Validator is an interface which extends both <b>ValidationAware</b> and <b>LocaleAware</b> and is used for looking up message texts and settting errors. When validators are called from the ValidationInterceptor, a DelegatingValidatorContext is created which delegates these calls to the Action if it implements these interfaces. If the Action does not implement LocaleAware, a LocaleAwareSupport instance is created which uses the Action's class to look up resource bundle texts, if available. If the action does not implement ValidationAware, an implementation which simply logs the validation errors is created and delegated to. When calling the validation framework from outside the ValidationInterceptor, any ValidatorContext implementation can be passed in.</p>
+
+<p>A new instance of the Validator is created by the framework each time it is asked to do work.  This provides for thread safety from within the framework.</p>
+
+<p>Validator classes may define any number of properties using the usual getX() setX() naming convention and have those properties set using &lt;param name="x"&gt;foo&lt;/param&gt; elements below the &lt;validator&gt; element. The values of these properties may then be used in the validate() method to parameterize the validation. Validators which extend the Support classes may also use the</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-object">Object</span> getFieldValue(<span class="code-object">String</span> name, Action action)</pre>
+</div></div>
+
+<p>method to get the field value of a named property from an Action.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Components.html

+<html>
+    <head>
+        <title>XWork - 
+        Components
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h2><a name="Components-Overview">Overview</a></h2>
+
+<p><a href="XWork.html" title="XWork">XWork</a> provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to allow a design pattern known as <b>Inversion of Control</b> (or <b>IoC</b> for short) to be applied to your actions or other arbitrary objects. In a nutshell, the IoC pattern allows a parent object (in this case XWork's ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <em>enabler</em>).</p>
+
+<p>You may also want to look at <a href="http://wiki.opensymphony.com//display/WW/Components" title="Components">WW:Components</a> to see how WW2 uses XWork's IoC architecture.</p>
+
+<h2><a name="Components-WhyIoC%3F">Why IoC?</a></h2>
+
+<p>So why is IoC useful? It means that you can develop components (generally services of some sort) in a top-down fashion, without the need to build a registry class that the client must then call to obtain the component instance.</p>
+
+<p>Traditionally when implementing services you are probably used to following steps similar to these:</p>
+<ol>
+	<li>Write the component (eg an ExchangeRateService)</li>
+	<li>Write the client class (eg an XWork action)</li>
+	<li>Write a registry class that holds the component object (eg Registry)</li>
+	<li>Write code that gives the component object to the registry (eg Registry.registerService(new MyExchangeRateService()))</li>
+	<li>Use the registry to obtain the service from your client class (eg ExchangeRateService ers = Registry.getExchangeRateService())</li>
+	<li>Make calls to the component from the client class (eg String baseCurrencyCode = ers.getBaseCurrency())</li>
+</ol>
+
+
+<p>Using IoC, the process is reduced to the following:</p>
+<ol>
+	<li>Write the component class (eg an ExchangeRateService)</li>
+	<li>Register the component class with XWork (eg componentManager.addEnabler(MyExchangeRateService, ExchangeRateAware))</li>
+	<li>Write the client class, making sure it implements the enabling interface (eg an XWork action that implements ExchangeRateAware)</li>
+	<li>Access the component instance directly from your client action (eg String baseCurencyCode = ers.getBaseCurrency())</li>
+</ol>
+
+
+<p>XWork takes care of passing components through to enabled action classes or other components.</p>
+
+<p>Some other benefits that IoC can provide include:</p>
+
+<ul>
+	<li>A component describes itself. When you instantiate a component, you can easily determine what dependencies it requires without looking at the source or using trial and error.</li>
+	<li>Dependencies can be discovered easily using reflection. This has many benefits ranging from diagram generation to runtime optimization (by determining in advance which components will be needed to fufill a request and preparing them asyncronously, for example).</li>
+	<li>Avoids the super-uber-mega-factory pattern where all the components of the app are held together by a single class that is directly tied back to other domain specific classes, making it hard to 'just use that one class'.</li>
+	<li>Adheres to Law of Demeter. Some people think this is silly, but in practise I've found it works much better. Each class is coupled to only what it actually uses (and it should never use too much) and no more. This encourages smaller responsibility specific classes which leads to cleaner design.</li>
+	<li>Allows context to be isolated and explicitly passed around. ThreadLocals may be ok in a web-app, but they aren't well suited for high concurrency async applications (such as message driven applications).</li>
+</ul>
+
+
+<h2><a name="Components-Configurationxwork.xml">Configuration - xwork.xml</a></h2>
+
+<p>The ComponentInterceptor class is used to apply the IoC pattern to XWork actions (ie, to supply components to actions). The ComponentInterceptor should be declared in the &lt;interceptors&gt; block of xwork.xml as follows:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-xml">&lt;interceptor name=<span class="code-quote">"component"</span>
+        class=<span class="code-quote">"com.opensymphony.xwork.interceptor.component.ComponentInterceptor"</span>/&gt;</pre>
+</div></div>
+
+<p>You should ensure that any actions that are to be supplied with components have this interceptor applied. (See <a href="Interceptors.html" title="Interceptors">XW:Interceptors</a> for information on how to apply interceptors to actions.)</p>
+
+<p>If you want to apply IoC to objects other than actions or other components, you will need to use the ComponentManager object directly.</p>
+
+<h2><a name="Components-WritingComponentClasses">Writing Component Classes</a></h2>
+
+<p>The actual component class can be virtually anything you like. The only constraints on it are that it must be a concrete class with a default constructor so that XWork can create instances of it as required. Optionally, a component may implement the Initializable and/or Disposable interfaces so it will receive lifecycle events just after it is created or before it is destroyed. Simply:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> class MyComponent <span class="code-keyword">implements</span> Intializable, Disposable {
+    <span class="code-keyword">public</span> void init () {
+         <span class="code-comment">//<span class="code-keyword">do</span> initialization here
+</span>    }
+
+    <span class="code-keyword">public</span> void dispose() {
+         <span class="code-comment">//<span class="code-keyword">do</span> any clean up necessary before garbage collection of <span class="code-keyword">this</span> component
+</span>    }
+}</pre>
+</div></div>
+
+<h2><a name="Components-ComponentDependencies">Component Dependencies</a></h2>
+
+<p>One feature that is not immediately obvious is that it is possible for components to depend on other components. For example if the ExchangeRateService described above depended on a Configuration component, XWork will pass the Configuration component through to the ExchangeRateService instance after ExchangeRateService is instantiated. Note that XWork automatically takes care of initializing the components in the correct order, so if A is an action or component that depends on B and C, and B depends on C and if A, B, and C have not been previously instantiated, the ComponentManager will in the following order:</p>
+
+<ol>
+	<li>Instantiate C and call it's init() method if it implements Initializable.</li>
+	<li>Instantiate B, then using the enabler method, set C to be used by B</li>
+	<li>Call B's init() method, if it implements Intitializable.</li>
+	<li>Set B using B's enabler method to be used by A.</li>
+</ol>
+
+
+<p>And so on and so forth. Of course, if there are instances of B or C that would be reused in this case, those instances would be passed using the enabler method rather than a new instance.</p>
+
+<h2><a name="Components-WritingEnablers">Writing Enablers</a></h2>
+
+<p>An enabler should consist of just a single method that accepts a single parameter. The parameter class should either be the component class that is to be enabled, or one of the component's superclasses. XWork does not care what the name of the enabler's method is.</p>
+
+<p>Here is an example of what the ExchangeRateAware enabler might look like:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-keyword">interface</span> ExchangeRateAware {
+    <span class="code-keyword">public</span> void setExchangeRateService(ExchangeRateService exchangeRateService);
+}</pre>
+</div></div>
+
+<p>Note that typically an enabler would be an interface, however there is nothing to prevent you from using a class instead if you so choose.</p>
+
+<h2><a name="Components-Writing%22Enableraware%22Actions">Writing "Enabler-aware" Actions</a></h2>
+
+<p>All an action needs to do is implement the relevant enabler interface. XWork will then call the action's enabler method just prior to the action's execution. As a simple example:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> class MyAction <span class="code-keyword">extends</span> ActionSupport <span class="code-keyword">implements</span> ExchangeRateAware {
+    ExchangeRateService ers;
+    
+    <span class="code-keyword">public</span> void setExchangeRateService(ExchangeRateService exchangeRateService) {
+        ers = exchangeRateService;
+    }
+    
+    <span class="code-keyword">public</span> <span class="code-object">String</span> execute() <span class="code-keyword">throws</span> Exception {
+        <span class="code-object">System</span>.out.println(<span class="code-quote">"The base currency is "</span> + ers.getBaseCurrency());
+    }
+}</pre>
+</div></div>
+
+<p>If you have an object that is not an action or another component, you must explictly tell XWork to supply any enabled components to your object by calling componentManager.initializeObject(enabledObject);</p>
+
+<h2><a name="Components-Usinganexternalreferenceresolver">Using an external reference resolver</a></h2>
+
+<p>You can also use an external reference resolver in XWork, i.e., references that will be resolved not by XWork itself. One such example is using an external resolver to integrate XWork with the <a href="http://www.springframework.org" title="Visit page outside Confluence">Spring Framework</a></p>
+
+<p>You just need to write an external reference resolver and then tell XWork to use it in the package declaration:</p>
+<div class="code"><div class="codeContent">
+<pre class="code-xml">&lt;package
+    name=<span class="code-quote">"default"</span>
+    externalReferenceResolver=<span class="code-quote">"com.atlassian.xwork.ext.SpringServletContextReferenceResolver"</span>&gt;</pre>
+</div></div>
+<p>Now, to use external references you do something like this:</p>
+<div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;external-ref name=<span class="code-quote">"foo"</span>&gt;</span>Foo<span class="code-tag">&lt;/external-ref&gt;</span></pre>
+</div></div>
+<p>Where the name attribute is the setter method name and Foo is the reference to lookup.</p>
+
+<p>For more details and sample code about this integration, take a look at the javadocs to the com.opensymphony.xwork.config.ExternalReferenceResolver class (unfortunately unavailable online) and at <a href="http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122" title="Visit page outside Confluence">XW-122</a></p>
+
+<p>-Chris</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Configuration.html

+<html>
+    <head>
+        <title>XWork - 
+        Configuration
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <ul>
+	<li>xwork.xml</li>
+	<li><a href="Logging.html" title="Logging">Logging</a></li>
+</ul>
+
+
+
+<h2><a name="Configuration-xwork.xml">xwork.xml</a></h2>
+
+<a name="Configuration-top"></a>
+<p>XWork is configured through the use of a file named xwork.xml in the root of the classpath which conforms to the DTD.  This file defines the action, interceptor, and result configurations and mappings. The following is a sample xwork.xml file; it's a condensed version of the one used in the XWork test cases.  It's a long example, but it exhibits all the major configuration possibilites:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-xml">&lt;!DOCTYPE xwork PUBLIC <span class="code-quote">"-//OpenSymphony Group//XWork 1.0//EN"</span>
+  <span class="code-quote">"http://www.opensymphony.com/xwork/xwork-1.0.dtd"</span>&gt;
+
+<span class="code-tag">&lt;xwork&gt;</span>
+  <span class="code-tag">&lt;package name=<span class="code-quote">"default"</span>&gt;</span>
+    <span class="code-tag">&lt;result-types&gt;</span>
+      <span class="code-tag">&lt;result-type name=<span class="code-quote">"chain"</span> class=<span class="code-quote">"com.opensymphony.xwork.ActionChainResult"</span>/&gt;</span>
+    <span class="code-tag">&lt;/result-types&gt;</span>
+
+    <span class="code-tag">&lt;interceptors&gt;</span>
+      <span class="code-tag">&lt;interceptor name=<span class="code-quote">"timer"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.TimerInterceptor"</span>/&gt;</span>
+      <span class="code-tag">&lt;interceptor name=<span class="code-quote">"logger"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.LoggingInterceptor"</span>/&gt;</span>
+      <span class="code-tag">&lt;interceptor name=<span class="code-quote">"chain"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.ChainingInterceptor"</span>/&gt;</span>
+      <span class="code-tag">&lt;interceptor name=<span class="code-quote">"params"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.ParametersInterceptor"</span>/&gt;</span>
+      <span class="code-tag">&lt;interceptor name=<span class="code-quote">"static-params"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.StaticParametersInterceptor"</span>/&gt;</span>
+      <span class="code-tag">&lt;interceptor name=<span class="code-quote">"test"</span> class=<span class="code-quote">"com.opensymphony.xwork.TestInterceptor"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"foo"</span>&gt;</span>expectedFoo<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/interceptor&gt;</span>
+
+      <span class="code-tag">&lt;interceptor-stack name=<span class="code-quote">"defaultStack"</span>&gt;</span>
+        <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"static-params"</span>/&gt;</span>
+        <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"params"</span>/&gt;</span>
+      <span class="code-tag">&lt;/interceptor-stack&gt;</span>
+      <span class="code-tag">&lt;interceptor-stack name=<span class="code-quote">"debugStack"</span>&gt;</span>
+        <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"timer"</span>/&gt;</span>
+        <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"logger"</span>/&gt;</span>
+      <span class="code-tag">&lt;/interceptor-stack&gt;</span>
+    <span class="code-tag">&lt;/interceptors&gt;</span>
+
+    <span class="code-tag">&lt;global-results&gt;</span>
+      <span class="code-tag">&lt;result name=<span class="code-quote">"login"</span> type=<span class="code-quote">"chain"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"actionName"</span>&gt;</span>login<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/result&gt;</span>
+    <span class="code-tag">&lt;/global-results&gt;</span>
+
+    <span class="code-tag">&lt;action name=<span class="code-quote">"Foo"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;param name=<span class="code-quote">"foo"</span>&gt;</span>17<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;param name=<span class="code-quote">"bar"</span>&gt;</span>23<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;result name=<span class="code-quote">"success"</span> type=<span class="code-quote">"chain"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"actionName"</span>&gt;</span>Bar<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/result&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"debugStack"</span>/&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"defaultStack"</span>/&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+
+    <span class="code-tag">&lt;action name=<span class="code-quote">"Bar"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;param name=<span class="code-quote">"foo"</span>&gt;</span>17<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;param name=<span class="code-quote">"bar"</span>&gt;</span>23<span class="code-tag">&lt;/param&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+
+    <span class="code-tag">&lt;action name=<span class="code-quote">"TestInterceptorParam"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"test"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"expectedFoo"</span>&gt;</span>expectedFoo<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/interceptor-ref&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+
+    <span class="code-tag">&lt;action name=<span class="code-quote">"TestInterceptorParamOverride"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"test"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"foo"</span>&gt;</span>foo123<span class="code-tag">&lt;/param&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"expectedFoo"</span>&gt;</span>foo123<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/interceptor-ref&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+  <span class="code-tag">&lt;/package&gt;</span>
+
+  <span class="code-tag">&lt;package name=<span class="code-quote">"bar"</span> extends=<span class="code-quote">"default"</span> namespace=<span class="code-quote">"/foo/bar"</span>&gt;</span>
+    <span class="code-tag">&lt;interceptors&gt;</span>
+      <span class="code-tag">&lt;interceptor-stack name=<span class="code-quote">"barDefaultStack"</span>&gt;</span>
+        <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"debugStack"</span>/&gt;</span>
+        <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"defaultStack"</span>/&gt;</span>
+      <span class="code-tag">&lt;/interceptor-stack&gt;</span>
+    <span class="code-tag">&lt;/interceptors&gt;</span>
+
+    <span class="code-tag">&lt;action name=<span class="code-quote">"Bar"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"barDefaultStack"</span>/&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+
+    <span class="code-tag">&lt;action name=<span class="code-quote">"TestInterceptorParamInheritance"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"test"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"expectedFoo"</span>&gt;</span>expectedFoo<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/interceptor-ref&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+
+  <span class="code-tag">&lt;/package&gt;</span>
+
+  <span class="code-tag">&lt;package name=<span class="code-quote">"abstractPackage"</span> namespace=<span class="code-quote">"/abstract"</span> abstract=<span class="code-quote">"true"</span>&gt;</span>
+    <span class="code-tag">&lt;action name=<span class="code-quote">"test"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>/&gt;</span>
+  <span class="code-tag">&lt;/package&gt;</span>
+
+  <span class="code-tag">&lt;package name=<span class="code-quote">"nonAbstractPackage"</span> extends=<span class="code-quote">"abstractPackage"</span> namespace=<span class="code-quote">"/nonAbstract"</span>/&gt;</span>
+
+  <span class="code-tag">&lt;package name=<span class="code-quote">"multipleInheritance"</span> extends=<span class="code-quote">"default,abstractPackage,bar"</span> namespace=<span class="code-quote">"multipleInheritance"</span>&gt;</span>
+    <span class="code-tag">&lt;action name=<span class="code-quote">"testMultipleInheritance"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;</span>
+      <span class="code-tag">&lt;result name=<span class="code-quote">"success"</span> type=<span class="code-quote">"chain"</span>&gt;</span>
+        <span class="code-tag">&lt;param name=<span class="code-quote">"actionName"</span>&gt;</span>foo<span class="code-tag">&lt;/param&gt;</span>
+      <span class="code-tag">&lt;/result&gt;</span>
+      <span class="code-tag">&lt;interceptor-ref name=<span class="code-quote">"barDefaultStack"</span>/&gt;</span>
+    <span class="code-tag">&lt;/action&gt;</span>
+  <span class="code-tag">&lt;/package&gt;</span>
+
+  <span class="code-tag">&lt;include file=<span class="code-quote">"includeTest.xml"</span>/&gt;</span>
+<span class="code-tag">&lt;/xwork&gt;</span></pre>
+</div></div>
+
+
+<h2><a name="Configuration-xwork.xmlelements">xwork.xml elements</a></h2>
+
+<h3><a name="Configuration-Package">Package <a name="Configuration-Package"></a></a></h3>
+
+<p>The package element has one required attribute, "name", which acts as the key to later reference this package. The "extends" attribute is optional and allows one package to inherit the configuration of one or more previous packages including all interceptor, interceptor-stack, and action configurations. Note that the configuration file is processed sequentially down the document, so the package referenced by an "extends" should be defined above the package which extends it. The "abstract" optional attribute allows you to make a package abstract, which will allow you to extend from it without the action configurations defined in the abstract package actually being available at runtime. (<a href="#Configuration-top" title="top on Configuration">see above for example</a>)</p>
+
+<table class='confluenceTable'>
+<tr>
+<th class='confluenceTh'> Attribute </th>
+<th class='confluenceTh'> Required </th>
+<th class='confluenceTh'> Description </th>
+</tr>
+<tr>
+<td class='confluenceTd'> name </td>
+<td class='confluenceTd'> <b>yes</b> </td>
+<td class='confluenceTd'> key to for other packages to reference </td>
+</tr>
+<tr>
+<td class='confluenceTd'> extends </td>
+<td class='confluenceTd'> no </td>
+<td class='confluenceTd'> inherits package behavior of the package it extends </td>
+</tr>
+<tr>
+<td class='confluenceTd'> namespace </td>
+<td class='confluenceTd'> no </td>
+<td class='confluenceTd'> see <a href="#Configuration-Namespace" title="Namespace on Configuration">Namespace</a> </td>
+</tr>
+<tr>
+<td class='confluenceTd'> abstract </td>
+<td class='confluenceTd'> no </td>
+<td class='confluenceTd'> declares package to be abstract (no action configurations required in package) </td>
+</tr>
+</table>
+
+<h4><a name="Configuration-Namespace">Namespace <a name="Configuration-Namespace"></a></a></h4>
+
+<p>The optional namespace attribute warrants its own discussion section. The namespace attribute allows you to segregate action configurations into namespaces, so that you may use the same action alias in more than one namespace with different classes, parameters, etc. This is in contrast to Webwork 1.x, where all action names and aliases were global and could not be re-used in an application. The default namespace, which is "" (an empty string) is used as a "catch-all" namespace, so if an action configuration is not found in a specified namespace, the default namespace will also be searched. This allows you to have global action configurations outside of the "extends" hierarchy, as well as to allow the previous Webwork 1.x behavior by not specifying namespaces. It is also intended that the namespace functionality can be used for security, for instance by having the path before the action name be used as the namespace by the Webwork 2.0 ServletDispatcher, thus allowing the use of J2EE declarative security on paths to be easily implemented and maintained. (<a href="#Configuration-top" title="top on Configuration">see above for example</a>)</p>
+<h3><a name="Configuration-ResultType">Result-Type</a></h3>
+
+<p>Result types define classes and map them to names to be referred in the action configuration results. This serves as a shorthand name-value pair for these classes.</p>
+
+
+<h3><a name="Configuration-Interceptors">Interceptors</a></h3>
+
+<p>Interceptors also serve as a name-value pairing for referring to specific Interceptor classes by a shorthand name where we use interceptor-ref elements, such as in Interceptor stacks and action configurations.</p>
+
+
+<h3><a name="Configuration-InterceptorStack">Interceptor-Stack</a></h3>
+
+<p>The interceptor-stack element allows you to assign a name for later referencing via interceptor-ref to an ordered list of interceptors. This allows you to create standard groups of interceptors to be used in a certain order. The interceptor stack name/value pairs are stored in the same map as the interceptor definitions, so anywhere you use an interceptor-ref to refer to an interceptor you may also refer to an interceptor stack.</p>
+<h3><a name="Configuration-InterceptorParameterization">Interceptor Parameterization</a></h3>
+
+<p>Interceptors are instantiated and stored at the ActionConfig level, i.e. there will be one instance per action configured in xwork.xml. These Interceptor instances may be parameterized at either the declaration level, where you map an Interceptor class to a name to be referenced later, like so:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;interceptor name=<span class="code-quote">"test"</span> class=<span class="code-quote">"com.opensymphony.xwork.TestInterceptor"</span>&gt;
+    &lt;param name=<span class="code-quote">"foo"</span>&gt;expectedFoo&lt;/param&gt;
+&lt;/interceptor&gt;</pre>
+</div></div>
+
+<p>or at the interceptor-ref level, either inside an interceptor-stack or in an action declaration, like so:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;interceptor-ref name=<span class="code-quote">"test"</span>&gt;
+    &lt;param name=<span class="code-quote">"expectedFoo"</span>&gt;expectedFoo&lt;/param&gt;
+&lt;/interceptor-ref&gt;</pre>
+</div></div>
+
+<p>Although it is allowed by the DTD, parameters applied to interceptor-refs which refer to interceptor-stack elements will NOT be applied, and will cause a warning message.</p>
+
+<h3><a name="Configuration-Globalresults">Global-results</a></h3>
+
+<p>The global results allows you to define result mappings which will be used as defaults for all action configurations and will be automatically inherited by all action configurations in this package and all packages which extend this package.</p>
+
+<h3><a name="Configuration-Action">Action</a></h3>
+
+<p>The action element allows the mapping of names to action classes. These names are used, along with the namespace described above, to retrieve the action config from the configuration. The action may also be parameterized by using the param elements, as above, which will set parameters into the Action at execution (with the help of the StaticParametersInterceptor). </p>
+
+<p>When defining actions, sometimes you actually don't need any class, but rather are just putting in a placeholder for accessing interceptors and results. You can use ActionSupport for a simple action that has all of the XWork features but doesn't actually do anything. In fact, rather than defining your action class, if you leave it empty it defaults to ActionSupport. </p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;action name=<span class="code-quote">"foo"</span>&gt;
+    ...
+&lt;/action&gt;</pre>
+</div></div>
+
+<p>The action may also have one or more results mapped to string return codes, such as "success", "error", or "input", which are the default 3 return states for actions, although ANY return string may be used and mapped to a result. The result, which is mapped to a result class by the "type" attribute which refers to the result-type name defined above, may also be parameterized by using the param element. </p>
+
+<p>There is one shortcut when defining results, as a lot of the time a result will have only one parameter (which is often a location to redirect to (when using XWork in the web sense)).</p>
+
+<p>Here is the long form of a result with a single location parameter:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;result name=<span class="code-quote">"test"</span>&gt;
+    &lt;param name=<span class="code-quote">"location"</span>&gt;foo.jsp&lt;/param&gt;
+&lt;/result&gt;</pre>
+</div></div>
+
+<p>and this is the 'shortcut' form:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;result name=<span class="code-quote">"test"</span>&gt;foo.jsp&lt;/result&gt;</pre>
+</div></div>
+
+<p>Note that this shortcut <b>only</b> works when there is a single parameter for the result and the result has defined what its default parameter is.</p>
+
+<p>If your result name is "success", then you can take this shortcut even further by just doing:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;result&gt;success.jsp&lt;/result&gt;</pre>
+</div></div>
+
+<div class="panel"><div class="panelContent" style="background-color: #ffffce; ">
+<p><img class="emoticon" src="./icons/emoticons/information.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> Tip: using the action class shorthand and the result shortcuts, you can do something as simple as this to define an XWork front-end to a result:</p>
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;action name=<span class="code-quote">"foo"</span>&gt;
+    &lt;result&gt;foo.jsp&lt;/result&gt;
+&lt;/action&gt;</pre>
+</div></div>
+</div></div>
+
+<p>Similar to the interceptor Syntax shown above, actions may be parametrized:</p>
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;action name=<span class="code-quote">"Foo"</span> class=<span class="code-quote">"com.opensymphony.xwork.SimpleAction"</span>&gt;
+    &lt;param name=<span class="code-quote">"foo"</span>&gt;17&lt;/param&gt;
+    ...
+&lt;/action&gt;</pre>
+</div></div>
+<p>In this example, it would be tried to call the setFoo() method in SimpleAction with the given value when Foo.action is called. If SimpleAction is model driven, setFoo() is invoked on the model.</p>
+
+<p>The action may also define one or more interceptor refs to either interceptors or interceptor stacks to be applied before and after the action execution (see the section on Interceptors below). The ordering of these interceptor refs determines the order in which they will be applied.</p>
+
+<h3><a name="Configuration-Includesusingmultipleconfigurationfiles">Includes - using multiple configuration files</a></h3>
+
+<p>The xwork.xml configuration file may be broken up into several files, each with its own set of package declarations, by using the &lt;include&gt; element zero or more times at the bottom of your xwork.xml file, like so:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;include file=<span class="code-quote">"includeTest.xml"</span>/&gt;</pre>
+</div></div>
+
+<p>These files will be processed, in order, in the same manner as the main xwork.xml, thus may have all of the same structures, including the &lt;include&gt; element. Although it is, therefore, possible to have packages in configuration files listed later in an include element extend packages defined in an earlier included file, it is not recommended. It should be considered best practice, in the case of using multiple configuration files, to declare default packages meant to be extended in the xwork.xml and to have no dependencies between sub-configuration files.</p>
+
+<h2><a name="Configuration-ConfigurationProviders">Configuration Providers</a></h2>
+
+<p>XWork configuration is handled through classes which implement the ConfigurationProvider interface.  The default implementation is the XmlConfigurationProvider class.  You can either create a new provider by implementing the ConfigurationProvider interface or you can extend the XmlConfigurationProvider class.  The XmlConfigurationProvider class includes a protected method called getInputStream() which is called to acquire the configuration InputStream which is expected to be an XML data stream.  The default implementation looks for a file called xwork.xml in the class path but by overriding the getInputStream() method you can pull configuration data from any source.</p>
+
+<p>Custom configuration providers must be registered with the ConfigurationManager before they will be used to load configuration data.  If no custom configuration providers are registered then the default configuration provider is used.  If any custom configuration providers are registered then the default configuration provider will no longer be used (although you could add a new instance of it yourself to include it in the list of providers which is searched).  To add a configuration provider just call the ConfigurationManager.addConfigurationProvider() method with the custom configuration provider as the argument.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Core Concepts.html

+<html>
+    <head>
+        <title>XWork - 
+         Concepts
+        </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h2><a name="CoreConcepts-XWorkCoreConcepts">XWork Core Concepts</a></h2>
+
+<p>XWork is based on a number of core concepts that helps to explain how the framework works. The core concepts can be broken down into two parts: Architecture Concepts and Terminology.</p>
+
+<h2><a name="CoreConcepts-ArchitectureConcepts">Architecture Concepts</a></h2>
+<ul>
+	<li>Explain Command Driven Architecture (in general)</li>
+	<li>Explain the implementation in XWork</li>
+</ul>
+
+
+<h2><a name="CoreConcepts-Terminology">Terminology</a></h2>
+
+<h3><a name="CoreConcepts-Actions">Actions</a></h3>
+
+<p>Actions are classes that get invoked in response to a request, execute some code and return a Result. Actions implement at a minimum a single method, execute(), that defines the entry point called by the framework. This method allows developers to define a unit of work that will be executed each time the Action is called.</p>
+
+<h3><a name="CoreConcepts-ActionContext">ActionContext</a></h3>
+
+<p>The ActionContext provides access to the execution environment in the form of named objects during an Action invocation. A new ActionContext is created for each invocation allowing developers to access/modify these properties in a thread safe manner. The ActionContext makes a number of properties available that are typically set to appropriate values by the framework. In WebWork 2 for example, the ActionContext session map wraps an underlying HttpSession object. This allows access to environment specific properties without tying the core framework to a specific execution environment. For more information, see ActionContext in <a href="Basics.html" title="Basics">Basics</a>.</p>
+
+<h3><a name="CoreConcepts-Interceptors">Interceptors</a></h3>
+
+<p>In XWork, Interceptors are objects that dynamically intercept Action invocations. They provide the developer with the opportunity to define code that can be executed before and/or after the execution of an action. They also have the ability to prevent an action from executing. Interceptors provide developers a way to encapulate common functionality in a re-usable form that can be applied to one or more Actions. See <a href="Interceptors.html" title="Interceptors">Interceptors</a> for further details.</p>
+
+<h3><a name="CoreConcepts-Stacks">Stacks</a></h3>
+
+<p>To handle the case where developers want to apply more than a single Interceptor to an Action, Stacks have been introduced. Stacks are an ordered list of Interceptors and/or other Stacks that get applied when an Action is invoked. Stacks centralize the declaration of Interceptors and provide a convenient way to configure mutiple actions.</p>
+
+<h3><a name="CoreConcepts-Results">Results</a></h3>
+
+<p>Results are string constants that Actions return to indicate the status of an Action execution. A standard set of Results are defined by default: error, input, login, none and success.  Developers are, of course, free to create their own Results to indicate more application specific cases.</p>
+
+<h3><a name="CoreConcepts-ResultTypes">Result Types</a></h3>
+
+<p>Result Types are classes that determine what happens after an Action executes and a Result is returned. Developers are free to create their own Result Types according to the needs of their application or environment. In WebWork 2 for example, Servlet and Velocity Result Types have been created to handle rendering views in web applications.</p>
+
+<h3><a name="CoreConcepts-Packages">Packages</a></h3>
+
+<p>Packages are a way to group Actions, Results, Result Types, Interceptors and Stacks into a logical unit that shares a common configuration. Packages are similiar to objects in that they can be extended and have individual parts overridden by "sub" packages.</p>
+
+<h3><a name="CoreConcepts-ValueStack">ValueStack</a></h3>
+
+<p>The ValueStack is a stack implementation built on top of an OGNL core. The OGNL expression language can be used to traverse the stack and retrieve the desired object. The OGNL expression language provides a number of additional features including: automatic type conversion, method invocation and object comparisons. For more information, see the <a href="http://ognl.org/" title="Visit page outside Confluence">OGNL Website</a>.</p>
+
+<h3><a name="CoreConcepts-Components">Components</a></h3>
+
+<p>XWork provides the ComponentManager interface (and a corresponding implementation in the DefaultComponentManager class) to apply a design pattern known as <b>Inversion of Control</b> (or IoC for short). In a nutshell, the IoC pattern allows a parent object (in this case XWork's ComponentManager instance) to control a client object (usually an action, but it could be any object that implements the appropriate <em>enabler</em>). See <a href="Components.html" title="Components">Components</a> for further details.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Custom Action Validation.html

+<html>
+    <head>
+        <title>XWork - 
+        Custom Action Validation
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>XWork's validators work great when you need to apply a common validation to your Action, particularly syntatic validations that simply check values for the correct format.  In a real world application, you might need to execute custom validation code that runs checks that are specific to an Action.  XWork allows you to, by implementing the <em>Validatable</em> interface, define a custom <em>validate()</em> method on your action, which will be called before the Action will be executed. </p>
+
+<p>For example, say you were developing a To Do list application, which contains a form that allows the user to modify an existing todo entry.  You need to create an Action which processes the submitted information and updates the todo information in database.  To check that the fields' values were in the correct formation, you might use the following XWork validators on the following fields:</p>
+
+<table class='confluenceTable'>
+<tr>
+<th class='confluenceTh'> Validator </th>
+<th class='confluenceTh'> Field(s) </th>
+</tr>
+<tr>
+<td class='confluenceTd'> <a href="Standard Validators.html#StandardValidators-RequiredFieldValidator" title="RequiredFieldValidator on Standard Validators">RequiredFieldValidator</a> </td>
+<td class='confluenceTd'> <em>id</em>,<em>name</em>,<em>description</em>,<em>completed</em> </td>
+</tr>
+<tr>
+<td class='confluenceTd'> <a href="Standard Validators.html#StandardValidators-StringLengthFieldValidator" title="StringLengthFieldValidator on Standard Validators">StringLengthFieldValidator</a> </td>
+<td class='confluenceTd'> <em>name</em> </td>
+</tr>
+<tr>
+<td class='confluenceTd'> <a href="Standard Validators.html#StandardValidators-IntRangeFieldValidator" title="IntRangeFieldValidator on Standard Validators">IntRangeFieldValidator</a> </td>
+<td class='confluenceTd'> <em>id</em> </td>
+</tr>
+</table>
+
+<p>However, you want to make sure the <em>id</em> of the todo form actually exists before you have the business layer make update the database.  While the XWork validators checked that the <em>id</em> field existed and contained a numeric value, you need to ensure custom validation code will be called during the validation process.</p>
+
+<p>The solution is to have your Action implement the <em>Validatable</em> interface, which defines a <em>validate()</em> method that you must implement.  If your action has the <em>DefaultWorkflowInterceptor</em> in its interceptor stack, your <em>validate()</em> method will be called.  If the <em>validate()</em> method, or any validators previously have generated any error messages, the chain will abort processing and return the <em>Action.INPUT</em> result (see <a href="DefaultWorkflowInterceptor.html" title="DefaultWorkflowInterceptor">DefaultWorkflowInterceptor</a> for more information).</p>
+
+<p>This is what the <em>validate()</em> method of our todo Action, which extends <em>ActionSupport</em>, might look like:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> void validate() {
+    <span class="code-keyword">if</span> (todoManager.getTodo(id) == <span class="code-keyword">null</span>) {
+        <span class="code-object">String</span> error = getText(<span class="code-quote">"todo.err.notFound"</span>);
+        addActionError(error);
+    }
+}</pre>
+</div></div>
+
+<p>The <em>todoManager</em> variable is a instance of the business management object that handles all todo database operations.  If the <em>id</em> field as submitted by the form doesn't exist, we lookup the text for the error and add it as an action error.</p>
+
+<p>If, however, you allowed todo entries to be modified in an other area of the application, you might consider converting this code into a custom Validator to avoid code duplication.  See <a href="Building a Validator.html" title="Building a Validator">Building a Validator</a> for details.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/DefaultWorkflowInterceptor.html

+<html>
+    <head>
+        <title>XWork - 
+        DefaultWorkflowInterceptor
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="code"><div class="codeContent">
+<pre class="code-java">&lt;interceptor name=<span class="code-quote">"workflow"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor"</span>/&gt;</pre>
+</div></div>
+
+<p>This interceptor  implements the workflow that was found in ActionSupport in WebWork 1.x. The following workflow steps are applied before the rest of the Interceptors and the Action are executed, and may short-circuit their execution:</p>
+
+<ol>
+	<li>If the Action implements <b>com.opensymphony.xwork.Validateable</b>, the <b>validate()</b> method is called on it, to allow the Action to execute any validation logic coded into it.</li>
+	<li>If the Action implements <b>com.opensymphony.xwork.ValidationAware</b> the <b>hasErrors()</b> method is called to check if the Action has any registered error messages (either Action-level or field-level). If the ValidationAware Action has any errors, <b>Action.INPUT</b> ("input") is returned without executing the rest of the Interceptors or the Action.</li>
+	<li>If the execution did not short-circuit in the step above, the rest of the Interceptors and the Action are executed by calling <b>invocation.invoke()</b></li>
+</ol>
+
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Dependencies.html

+<html>
+    <head>
+        <title>XWork - 
+        Dependencies
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>Dependencies are split into runtime and compile time dependencies.</p>
+
+<ul>
+	<li>Runtime dependencies are stored in CVS in the <b>lib/core</b> directory.</li>
+	<li>Compile time dependencies are stored in CVS in the <b>lib/build</b> directory.</li>
+</ul>
+
+
+<p>You can see all the dependenies as well as their version numbers by looking at the <b>libraries.txt</b> file located in each directory.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Documentation.html

+<html>
+    <head>
+        <title>XWork - 
+        Documentation
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="information-block" align='center'><div class='informationMacroPadding'><table cellpadding='5' width='85%' cellspacing='0' class='warningMacro' border='0'><tr><td width='16' valign='top'><img src="/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>These documents are very out of date. As the majority of XWork users are also WebWork users, we've decided to put all our effort in to enhancing the WebWork documentation. As such, these documents may be out of date. However, as of XWork 1.1, a large amount of JavaDocs have been added to XWork. We hope they are useful to you. You can also read the WebWork documentation, as it may provide useful elements about XWork</td></tr></table></div></div>
+
+<h3><a name="Documentation-Overview">Overview</a></h3>
+<ul>
+	<li><a href="Introduction.html" title="Introduction">Introduction</a>
+	<ul>
+		<li>What is Xwork?</li>
+		<li>How does Webwork 2.0 relate to Xwork?</li>
+	</ul>
+	</li>
+</ul>
+
+
+<h3><a name="Documentation-ReferenceGuide">Reference Guide</a></h3>
+<ul>
+	<li><a href="Core Concepts.html" title="Core Concepts">Core Concepts</a>: Terminology and an introduction to XWork</li>
+	<li><a href="XWork layers.html" title="XWork layers">XWork layers</a></li>
+	<li><a href="Configuration.html" title="Configuration">Configuration</a>: xwork.xml</li>
+	<li><a href="Ognl.html" title="Ognl">Ognl</a></li>
+	<li><a href="Localization.html" title="Localization">Localization</a></li>
+	<li><a href="Type Conversion.html" title="Type Conversion">Type Conversion</a></li>
+	<li><a href="Interceptors.html" title="Interceptors">Interceptors</a></li>
+	<li><a href="Validation Framework.html" title="Validation Framework">Validation Framework</a></li>
+	<li><a href="Components.html" title="Components">Components</a>: Inversion of Control</li>
+</ul>
+
+
+<h3><a name="Documentation-XWorkVersions">XWork Versions</a></h3>
+<ul>
+	<li>Current Release
+	<ul>
+		<li>Release Notes
+		<ul>
+			<li><a href="XWork 1.0.6.html" title="XWork 1.0.6">XWork 1.0.6</a></li>
+			<li><a href="XWork 1.0.5.html" title="XWork 1.0.5">XWork 1.0.5</a></li>
+			<li><a href="XWork 1.0.4.html" title="XWork 1.0.4">XWork 1.0.4</a></li>
+			<li><a href="XWork 1.0.3.html" title="XWork 1.0.3">XWork 1.0.3</a></li>
+			<li><a href="XWork 1.0.2.html" title="XWork 1.0.2">XWork 1.0.2</a></li>
+			<li><a href="XWork 1.0.1.html" title="XWork 1.0.1">XWork 1.0.1</a></li>
+		</ul>
+		</li>
+		<li><a href="Dependencies.html" title="Dependencies">Dependencies</a></li>
+	</ul>
+	</li>
+	<li>Upgrading from previous versions
+	<ul>
+		<li><a href="Upgrading from 1.0.4.html" title="Upgrading from 1.0.4">Upgrading from 1.0.4</a></li>
+		<li><a href="Upgrading from 1.0.3.html" title="Upgrading from 1.0.3">Upgrading from 1.0.3</a></li>
+		<li><a href="Upgrading from 1.0.2.html" title="Upgrading from 1.0.2">Upgrading from 1.0.2</a></li>
+		<li><a href="Upgrading from 1.0.1.html" title="Upgrading from 1.0.1">Upgrading from 1.0.1</a></li>
+		<li><a href="Upgrading from 1.0.html" title="Upgrading from 1.0">Upgrading from 1.0</a></li>
+	</ul>
+	</li>
+</ul>
+
+
+
+<h3><a name="Documentation-DocumentationTasksRemaining">Documentation Tasks Remaining</a></h3>
+
+<ul>
+	<li>Merge XWork specific docs from WebWork.  In particular:
+	<ul>
+		<li>config docs</li>
+	</ul>
+	</li>
+	<li>Description for all interceptors</li>
+	<li>Beef up <a href="Basics.html" title="Basics">Basics</a></li>
+	<li>Make sure we document ActionChaining somewhere</li>
+</ul>
+
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/ExpressionValidator Tips.html

+<html>
+    <head>
+        <title>XWork - 
+        ExpressionValidator Tips
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <h2><a name="ExpressionValidatorTips-ExpressionValidatorTips">ExpressionValidator Tips</a></h2>
+
+<h3><a name="ExpressionValidatorTips-Fieldnamereferences">Fieldname references</a></h3>
+<p>As long as your Action provides a "setter" and a "getter" for your form fields, you can simply refer to them in your expression by name.</p>
+
+<p>Given this form field:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;input type=text name=<span class="code-quote">"foo"</span>&gt;</span></pre>
+</div></div>
+
+<p>And this Action fragment</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">private</span> <span class="code-object">String</span> foo;
+<span class="code-keyword">public</span> void setFoo(<span class="code-object">String</span> Foo) { <span class="code-keyword">this</span>.foo = foo; }
+<span class="code-keyword">public</span> <span class="code-object">String</span> getFoo() {<span class="code-keyword">return</span> foo; }</pre>
+</div></div>
+
+<p>Your form fields are available to your expression like this:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">foo == <span class="code-quote">"sometext"</span></pre>
+</div></div>
+
+
+<h3><a name="ExpressionValidatorTips-Advancedfieldreferences">Advanced field references</a></h3>
+<p>If you expose an object in your Action via a getter, you can directly set (from the form) and access (from the validation expression) properties <b>within</b> that object.</p>
+
+<p>Given this form fragment:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;input type=text name=<span class="code-quote">"address.firstName"</span>&gt;</span>
+<span class="code-tag">&lt;input type=text name=<span class="code-quote">"address.lastName"</span>&gt;</span></pre>
+</div></div>
+
+<p>And this Action fragment:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">private</span> Address address;
+<span class="code-keyword">public</span> void setAddress(Address address) { <span class="code-keyword">this</span>.address = address; }
+<span class="code-keyword">public</span> Address getAddress() {<span class="code-keyword">return</span> address; }</pre>
+</div></div>
+
+<p>Your validation expression can do this:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">address.firstName == <span class="code-quote">"Joe"</span> and address.lastName == <span class="code-quote">"Bloe"</span></pre>
+</div></div>
+
+<div class="information-block" align='center'><div class='informationMacroPadding'><table cellpadding='5' width='85%' cellspacing='0' class='noteMacro' border='0'><tr><td width='16' valign='top'><img src="/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>
+<p>Some use this feature to expose their "model" or "domain" objects directly to their forms and to their validation code.</p>
+
+<p>This can be incredibly powerful but should be used with caution as it allows anybody monkey-ing with URL's (or custom forms) to inject data directly into your domain objects that you might not want to have there.</p>
+
+<p>Jason said it well: "It's a great tool, but it's a sharp tool, and you can cut yourself with it."</p></td></tr></table></div></div>
+
+
+<h3><a name="ExpressionValidatorTips-ExpressionValidatorsuseOGNL">ExpressionValidators use OGNL</a></h3>
+<p>OGNL: Pronounced like the "ogonal" part of orthogonal.</p>
+
+<p>The ExpressionValidator expressions are simply OGNL expressions that evaluate to true or false.  You have the complete OGNL language and stack available to you when writing ExpressionValidator expressions.</p>
+
+<p>For most of what you probably want to do, you don't need to worry about all that.  Just reference your fields by name, use standard comparison operators, etc.</p>
+
+<p>But if you want the full meal deal there is a huge amount of power (and complexity) available if you want to take the time to plumb the depths of OGNL.  The OGNL docs are here:</p>
+
+<p><a href="http://www.ognl.org/" title="Visit page outside Confluence">&#104;ttp://www.ognl.org/</a></p>
+
+
+<h3><a name="ExpressionValidatorTips-Falseexpressionstriggerthevalidationerror">False expressions trigger the validation error</a></h3>
+
+<p>I often find myself thinking of my validation tests exactly opposite of how WebWork thinks of them.</p>
+
+<p>If you want to trigger a validation error if two fields are inequal, you might be inclined to do this:</p>
+
+<div class="code"><div class="codeHeader"><b>Probably not what you want!</b></div><div class="codeContent">
+<pre class="code-java">email != emailVerified</pre>
+</div></div>
+
+<p>That will do exactly the opposite of what you expect.  It will return "false" when the fields are equal (and trigger a validation error) and "true" when the fields are not equal (not triggering a validation error).</p>
+
+<p>You want to do this:</p>
+
+<div class="code"><div class="codeHeader"><b>Probably what you want</b></div><div class="codeContent">
+<pre class="code-java">email == emailVerified</pre>
+</div></div>
+
+<p>If your brain works like mine, you'll probably end up negating a lot of your expressions.  If you have long or compound expressions that evaluate to true, just wrap the whole thing in parenthesis to negate it:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">!
+(
+  ( chosenAddressId.intValue() eq -1 )
+  and
+  ( regionId.intValue() eq -1 )
+  and
+  ( ( countryId.intValue() eq 1 ) or ( countryId.intValue() eq 2 ) )
+)</pre>
+</div></div>
+
+
+<h3><a name="ExpressionValidatorTips-Expressioncanbemultiline">Expression can be multi-line</a></h3>
+<p>As you can see above, your expression can span as many lines as you like.  This really helps keep complex expressions readable.</p>
+
+
+<h3><a name="ExpressionValidatorTips-Usethevalidationmessagefordebugging">Use the validation message for debugging</a></h3>
+<p>A common mistake is to incorrectly refer to the field you want to compare.  You can verify that the field you <b>think</b> you're referring to is the field you're <b>actually</b> referring to by creating an ExpressionValidator that always returns false (meaning that it always triggers a validation error), and emitting the field values in its message like so:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">&lt;field name=<span class="code-quote">"user.password_confirm"</span>&gt;
+  &lt;field-validator type=<span class="code-quote">"fieldexpression"</span>&gt;
+    &lt;param name=<span class="code-quote">"expression"</span>&gt;<span class="code-keyword">false</span>&lt;/param&gt;
+    &lt;message&gt;${password}   ${password_verified}&lt;/message&gt;
+  &lt;/field-validator&gt;
+&lt;/field&gt;</pre>
+</div></div>
+
+
+<h3><a name="ExpressionValidatorTips-SpecialhandlingofnullandStringequality">Special handling of null and String equality</a></h3>
+
+<p><b>nulls</b><br/>
+The comparison operators used by the ExpressionValidator will internally handle nulls and, generally, "do the right thing" with regard to comparisons containing fields with null values.  Recall that in java you might be inclined to write a test like so...</p>
+
+<div class="code"><div class="codeHeader"><b>What you'd do in Java</b></div><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">if</span>( field != <span class="code-keyword">null</span> &amp;&amp; field.intValue() == 2 )</pre>
+</div></div>
+
+<p>...to ensure your field wasn't null so you avoid a potential null-pointer exception in the rest of the test.  This is unnecessary in OGNL, simply do this:</p>
+
+<div class="code"><div class="codeHeader"><b>What you do in an ExpressionValidator</b></div><div class="codeContent">
+<pre class="code-java">field.intValue() == 2</pre>
+</div></div>
+
+<p><b>Strings</b><br/>
+There is also  no need to do .equals() comparisons on strings.  Recall that in Java you usually do not compare two strings with the == operator, you use the .equals() method of your String object instead.  But the OGNL expression language will automatically do a .equals() comparison for you when you use the == operator on two Strings.</p>
+
+<p>These two are equivalent:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">password.equals(passwordVerified)</pre>
+</div></div>
+
+<p>... is equivalent to ...</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">password == passwordVerified</pre>
+</div></div>
+
+<p><b>From the OGNL docs:</b></p>
+<blockquote>
+<p><em>Equality is tested for as follows. If either value is null, they are equal if and only if both are null. If they are the same object or the equals() method says they are equal, they are equal. If they are both Numbers, they are equal if their values as double-precision floating point numbers are equal. Otherwise, they are not equal. These rules make numbers compare equal more readily than they would normally, if just using the equals method.</em></p></blockquote>
+
+
+<h3><a name="ExpressionValidatorTips-FieldValidatorsdonotshortcircuitExpressionValidators.">FieldValidators do not short-circuit ExpressionValidators.</a></h3>
+
+<p>Ever.</p>
+
+<p>See the docs (currently only available on the Wiki docs) for information about short-circuiting:</p>
+
+<p>  <a href="http://wiki.opensymphony.com/display/XW/Validation+Framework" title="Visit page outside Confluence">&#104;ttp://wiki.opensymphony.com/display/XW/Validation+Framework</a></p>
+
+<p>The upshot is that a FieldValidator (regardless of whether you use the &lt;validator&gt; or &lt;field-validator&gt; syntax) will <b>never</b> short-circuit an ExpressionValidator.  And since most of the built-in validators are FieldValidators, you probably will not get the short-circuit behavior you want by mixing FieldValidators and Expressionvalidators.</p>
+
+<p>Given this example...</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;validator type=<span class="code-quote">"required"</span> short-circuit=<span class="code-quote">"true"</span>&gt;</span>
+    <span class="code-tag">&lt;param name=<span class="code-quote">"fieldName"</span>&gt;</span>bar<span class="code-tag">&lt;/param&gt;</span>
+    <span class="code-tag">&lt;message&gt;</span>You must enter a value for bar.<span class="code-tag">&lt;/message&gt;</span>
+<span class="code-tag">&lt;/validator&gt;</span>
+
+<span class="code-tag">&lt;validator type=<span class="code-quote">"expression"</span>&gt;</span>
+    <span class="code-tag">&lt;param name=<span class="code-quote">"expression"</span>&gt;</span>foo gt bar<span class="code-tag">&lt;/param&gt;</span>
+    <span class="code-tag">&lt;message&gt;</span>foo must be great than bar.<span class="code-tag">&lt;/message&gt;</span>
+<span class="code-tag">&lt;/validator&gt;</span></pre>
+</div></div>
+
+<p>...the ExpresionValidator will <b>always</b> run.</p>
+
+<p>If you find yourself needing to short-circuit a FieldValidator you can always create an ExpressionValidator that does the equivalent work of the FieldValidator.  Once your validation check is implemented as an ExpressionValidator it will be short-circuited by other validators.</p>
+
+
+<h3><a name="ExpressionValidatorTips-ExpressionValidatorsdoshortcircuitFieldValidators.">ExpressionValidators do short-circuit FieldValidators.</a></h3>
+
+<p>An ExpressionValidator <b>will</b> short-circuit FieldValidators.</p>
+
+<p>If we rewrite the above example to place the short-circuit on the ExpressionValidator...</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;validator type=<span class="code-quote">"required"</span>&gt;</span>
+    <span class="code-tag">&lt;param name=<span class="code-quote">"fieldName"</span>&gt;</span>bar<span class="code-tag">&lt;/param&gt;</span>
+    <span class="code-tag">&lt;message&gt;</span>You must enter a value for bar.<span class="code-tag">&lt;/message&gt;</span>
+<span class="code-tag">&lt;/validator&gt;</span>
+
+<span class="code-tag">&lt;validator type=<span class="code-quote">"expression"</span> short-circuit=<span class="code-quote">"true"</span>&gt;</span>
+    <span class="code-tag">&lt;param name=<span class="code-quote">"expression"</span>&gt;</span>foo gt bar<span class="code-tag">&lt;/param&gt;</span>
+    <span class="code-tag">&lt;message&gt;</span>foo must be great than bar.<span class="code-tag">&lt;/message&gt;</span>
+<span class="code-tag">&lt;/validator&gt;</span></pre>
+</div></div>
+
+<p>... we get behavior wherein a validation error by the ExpressionValidator will cause the "required" FieldValidator to be skipped.</p>
+
+
+<h3><a name="ExpressionValidatorTips-TurnonXMLreloading">Turn on XML reloading</a></h3>
+<p>During development/debugging of expressions, it can be immensely helpful to turn on XML reloading.  This will allow your changes to the -validation.xml files be noticed by WebWork without a restart.</p>
+
+<p>In webwork.properties set...</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">webwork.configuration.xml.reload = <span class="code-keyword">true</span></pre>
+</div></div>
+
+<p>See the docs about the webwork.properties file and where it should be placed.</p>
+
+<div class="information-block" align='center'><div class='informationMacroPadding'><table cellpadding='5' width='85%' cellspacing='0' class='noteMacro' border='0'><tr><td width='16' valign='top'><img src="/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>
+<p>Note that if your development environment has you editing your "main" code files in one place and then copying them into your app-server for deployment <em>xml.reload</em> only reloads the <b>deployed</b> copies.</p>
+
+<p>That's a no-duh, but it's easy to forget in IDE's like NetBeans.  NetBeans maintains the "main" code in a separate directory from the code actually used by the deployed app (which it locates in the build directory).</p>
+
+<p>If this is the case with your dev environment, no worries, just edit the <b>deployed</b> -validation.xml file while you're developing and debugging and then copy the final changes back to your "main" file when you're done.</p>
+
+<p><font color="red">Be sure to copy those changes back to your main file before you rebuild!!</font></p></td></tr></table></div></div>
+
+<h3><a name="ExpressionValidatorTips-Letterbasedcomparisonoperatorsareyourfriends">Letter-based comparison operators are your friends</a></h3>
+
+<p><b>the problem</b><br/>
+Many of the normal comparison operators cannot be used un-escaped in your XML validation file. For example, you can't use an expression like this...</p>
+
+<div class="code"><div class="codeHeader"><b>Won't work</b></div><div class="codeContent">
+<pre class="code-java">field &gt; 2</pre>
+</div></div>
+
+<p>...because the greater-than sign has special meaning in XML.</p>
+
+<p><b>the solution</b><br/>
+Some would suggest you escape the greater-than sign like this:</p>
+
+<div class="code"><div class="codeHeader"><b>This will work</b></div><div class="codeContent">
+<pre class="code-java">field &amp;amp;gt; 2</pre>
+</div></div>
+
+<p>Others have suggested that you use a CDATA block like this (note, I have not personally tried this):</p>
+
+<div class="code"><div class="codeHeader"><b>This will also work</b></div><div class="codeContent">
+<pre class="code-java">&lt;![CDATA[ field &gt; 2 ]]&gt;</pre>
+</div></div>
+
+<p>But I find both of those rather ugly.  The easier thing to do is to just remember that all of the OGNL comparison operators have letter-based notations.  So the above (within an ExpressionValidator) works perfectly well:</p>
+
+<div class="code"><div class="codeHeader"><b>This will work, and look how pretty it is</b></div><div class="codeContent">
+<pre class="code-java">field gt 2</pre>
+</div></div>
+
+<p>The letter-based notation for each of the OGNL comparison operators can be found in this section of the OGNL docs:</p>
+
+<p><a href="http://www.ognl.org/2.6.7/Documentation/html/LanguageGuide/apa.html#operators" title="Visit page outside Confluence">&#104;ttp://www.ognl.org/2.6.7/Documentation/html/LanguageGuide/apa.html#operators</a></p>
+
+<p>I've gotten into the habit of using letter-based operator syntax for all my OGNL comparison operators whether they need to be escaped or not.  Keeps my brain in the "OGNL" groove (and helps remind this is <b>not</b> java and that there are some subtle differences such as the null and String handling noted above).</p>
+
+<div class="information-block" align='center'><div class='informationMacroPadding'><table cellpadding='5' width='85%' cellspacing='0' class='noteMacro' border='0'><tr><td width='16' valign='top'><img src="/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>OGNL's letter-based comparison operators feel comfortingly perl-ish.  But remember that OGNL's letter-based comparison operators work on <b>all</b> datatypes, unlike perl where the letter-based comparison operators work only on strings.</td></tr></table></div></div>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Generic Object Validation.html

+<html>
+    <head>
+        <title>XWork - 
+        Generic Object Validation
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>XWork's validation framework is not just limited to Actions.  It can be used to validate virtually any object.  Once you've set up your validator config file (<b>validators.xml</b>) and your validation rules (<b>ClassName-validation.xml</b>), all it takes are a couple lines of code:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-object">String</span> context = <span class="code-keyword">null</span>;
+ValidatorContext context = <span class="code-keyword">new</span> DelegatingValidatorContext(objectToValidate);
+ActionValidatorManagerFactory.getInstance().validate(objectToValidate, <span class="code-keyword">null</span>, context);</pre>
+</div></div>
+
+<p>This will cause any errors to be logged (where it gets logged to depends on how commons-logging is configured).  </p>
+
+<p>Ideally, you would either implement your own ValidatorContext to handle how error messages are logged and evaluated, or have your objects that are to be evaluated implement ValidationAware, TextProvider and/or LocaleProvider.</p>
+
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Interceptors.html

+<html>
+    <head>
+        <title>XWork - 
+        Interceptors
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <ul>
+	<li>Overview</li>
+	<li><a href="PrepareInterceptor.html" title="PrepareInterceptor">PrepareInterceptor</a></li>
+	<li><a href="ValidationInterceptor.html" title="ValidationInterceptor">ValidationInterceptor</a></li>
+	<li><a href="DefaultWorkflowInterceptor.html" title="DefaultWorkflowInterceptor">DefaultWorkflowInterceptor</a></li>
+</ul>
+
+
+<h2><a name="Interceptors-Overview">Overview</a></h2>
+
+<p>Interceptors allow you to define code to be executed before and/or after the execution of an action. They are defined outside the action class, yet have access to the action and the action execution environment at runtime, allowing you to encapsulate cross-cutting code and provide separation of concerns. </p>
+
+<p>Interceptors are given the ActionInvocation object at runtime, and may do whatever processing needed, then forward processing to the rest of the ActionInvocation, which will either call the next Interceptor or the Action, if there are no more Interceptors, and do whatever post-processing needed. </p>
+
+<p>Interceptors may also decide to short-circuit processing and return whatever result string desired WITHOUT forwarding processing, thus keeping the Action from executing. This ability should be used with caution, however, as any data loading or processing expected to be done by the Action will not happen. </p>
+
+<p>Here is the invoke() method from ActionInvocation, which calls the Interceptors and the Action:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-object">String</span> invoke() <span class="code-keyword">throws</span> Exception {
+        <span class="code-keyword">if</span> (executed) {
+            <span class="code-keyword">throw</span> <span class="code-keyword">new</span> IllegalStateException(<span class="code-quote">"Action has already executed"</span>);
+        }
+
+        <span class="code-keyword">if</span> (interceptors.hasNext()) {
+            Interceptor interceptor = (Interceptor) interceptors.next();
+            result = interceptor.intercept(<span class="code-keyword">this</span>);
+        } <span class="code-keyword">else</span> {
+            result = action.execute();
+            executed = <span class="code-keyword">true</span>;
+        }
+
+        <span class="code-keyword">return</span> result;
+    }</pre>
+</div></div>
+
+<p>It may not be immediately apparent how the rest of the Interceptors and the Action come to be called from the code snippet. For this we need to look at the Interceptor implementation in <b>AroundInterceptor</b>:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-object">String</span> intercept(ActionInvocation invocation) <span class="code-keyword">throws</span> Exception {
+        before(invocation);
+
+        result = invocation.invoke();
+        after(invocation);
+
+        <span class="code-keyword">return</span> result;
+    }</pre>
+</div></div>
+
+<p>Here we can see that the Interceptor calls back into the ActionInvocation.invoke() to tell the ActionInvocation to continue down the chain and eventually executes the Action. It is here that the Interceptor can decide not to forward to the rest of the Interceptors and the Action, and choose instead to return a return code. </p>
+
+<p>It is also important to know what the AroundInterceptor is doing when you extend it to implement your own Interceptors.</p>
+
+<p>The AroundInterceptor defines a base class for interceptor implementations. It delegates calls to subclasses, which must implement the abstract methods before() and after(). The before() call is first called, then the rest of the ActionInvocation is called and the String result is saved (and is available to the Interceptor implementation during the after() method). Finally, the after() method is called and the result is returned. </p>
+
+<p><img class="emoticon" src="./icons/emoticons/information.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> Note that all Interceptor implementations must be threadsafe.</p>
+
+
+<h2><a name="Interceptors-UtilityInterceptors"><a name="Interceptors-Utility"></a> Utility Interceptors</a></h2>
+
+<p>The TimerInterceptor and LoggingInterceptor are provided as simple examples and utilities. </p>
+
+<ul>
+	<li>The <b>LoggingInterceptor</b> simply logs before and after executing the rest of the ActionInvocation.</li>
+	<li>The <b>TimerInterceptor</b> times the execution of the remainder of the ActionInvocation.<br/>
+The TimerInterceptor does not extend AroundInterceptor because it needs to keep some state (the start time) from before the rest of the execution. Interceptors must be stateless, so it is impossible to save this in an instance field. It is a good rule of thumb to say that if your interceptor needs to maintain information from the beginning to the end of the interceptor call, it should implement Interceptor directly, not subclass AroundInterceptor. Here is the code for <b>intercept()</b> in TimerInterceptor:</li>
+</ul>
+
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-object">String</span> intercept(ActionInvocation dispatcher) <span class="code-keyword">throws</span> Exception {
+        <span class="code-object">long</span> startTime = <span class="code-object">System</span>.currentTimeMillis();
+        <span class="code-object">String</span> result = dispatcher.invoke();
+        <span class="code-object">long</span> executionTime = <span class="code-object">System</span>.currentTimeMillis() - startTime;
+        log.info(<span class="code-quote">"Processed action "</span> + dispatcher.getProxy().getActionName() + <span class="code-quote">" in "</span> + executionTime + <span class="code-quote">"ms."</span>);
+
+        <span class="code-keyword">return</span> result;
+    }</pre>
+</div></div>
+
+<p>It is important to remember to call <b>invoke()</b> on the ActionInvocation if you directly implement Interceptor, otherwise the rest of the Interceptors and the Action will not be executed.</p>
+
+<h2><a name="Interceptors-ParameterInterceptorspopulatingyourAction"><a name="Interceptors-Parameter"></a> Parameter Interceptors - populating your Action</a></h2>
+
+<p>The StaticParametersInterceptor and ParametersInterceptor populate your Action fields during the ActionInvocation execution. </p>
+
+<ul>
+	<li>The <b>StaticParametersInterceptor</b> applies the parameters defined in the Action configuration with the &lt;param&gt; elements.</li>
+	<li>The <b>ParametersInterceptor</b> populates the Action with the parameters passed in as part of the request.</li>
+</ul>
+
+
+<p>The StaticParametersInterceptor should be applied before the ParametersInterceptor so that the static parameters may be set as the defaults and overridden by the request parameters.</p>
+
+<h2><a name="Interceptors-ModelDrivenInterceptorchoosingyourmodel"><a name="Interceptors-ModelDriven"></a> ModelDrivenInterceptor - choosing your model</a></h2>
+
+<p>Normally, the <b>StaticParameterInterceptor</b> and the <b>ParametersInterceptor</b> apply themselves directly to the Action.  Using the ModelDrivenInterceptor, you can specify an alternate object to have the parameters applied to instead.</p>
+
+<p>Consider the following Action:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> class AddContactAction <span class="code-keyword">implements</span> Action {
+  <span class="code-keyword">private</span> <span class="code-object">String</span> name;
+  <span class="code-keyword">private</span> <span class="code-object">String</span> addr;
+  <span class="code-keyword">private</span> <span class="code-object">String</span> city;
+
+  <span class="code-keyword">public</span> void setName(<span class="code-object">String</span> name) { <span class="code-keyword">this</span>.name = name ; }
+  <span class="code-keyword">public</span> void setAddr(<span class="code-object">String</span> addr) { <span class="code-keyword">this</span>.addr = addr ; }
+  <span class="code-keyword">public</span> void setCity(<span class="code-object">String</span> city) { <span class="code-keyword">this</span>.city = city ; }
+
+  <span class="code-keyword">public</span> <span class="code-object">String</span> execute() {
+     Contact contact = <span class="code-keyword">new</span> Contact();
+     contact.setName(name);
+     contact.setAddr(addr);
+     contact.setCity(city);
+
+     <span class="code-comment">// save contact information here
+</span>  }
+}</pre>
+</div></div>
+
+<p>We can see that our action will be populated with name, addr, and city parameters if they are passed in.  In the execute we copy these values to a contact object and save the contact.</p>
+
+<p>Here's the ModelDriven interface:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-keyword">interface</span> ModelDriven {
+  <span class="code-keyword">public</span> <span class="code-object">Object</span> getModel();
+}</pre>
+</div></div>
+
+<p>Let's apply the ModelDriven interface to Action above:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> class AddContactAction <span class="code-keyword">implements</span> Action, ModelDriven {
+  <span class="code-keyword">private</span> Contact contact = <span class="code-keyword">new</span> Contact();
+
+  <span class="code-keyword">public</span> <span class="code-object">Object</span> getModel() { <span class="code-keyword">return</span> <span class="code-keyword">this</span>.contact ; }
+
+  <span class="code-keyword">public</span> void execute() {
+    <span class="code-comment">// save the contact information
+</span>  }
+}</pre>
+</div></div>
+
+<p>Now the ParametersInterceptor and the StaticParametersInterceptor will be applied directly to our Contact so when execute gets called, this.contact will already be populated with all the information we need.  Neat, huh?  </p>
+
+<p>Behavior similar to model driven can be achieved just using the parameter interceptor.  For example, rather than implementing ModelDriven, we could have written:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> class AddContactAction <span class="code-keyword">implements</span> Action {
+  <span class="code-keyword">private</span> Contact contact = <span class="code-keyword">new</span> Contact();
+
+  <span class="code-keyword">public</span> Contact getContact { <span class="code-keyword">return</span> <span class="code-keyword">this</span>.contact ; }
+
+  <span class="code-keyword">public</span> void execute() {
+    <span class="code-comment">// save the contact information
+</span>  }
+}</pre>
+</div></div>
+
+<p>The difference between this Action and the previous ModelDriven action is twofold:</p>
+
+<ul>
+	<li>Using the ModelDriven action, we can reference our parameters name, addr, and city.  Also, the Model (Contact) will be pushed onto the ValueStack so we'll have Contact and AddContactAction on the value stack</li>
+	<li>When not using the ModelDriven action, we need to reference our parameters as contact.name, contact.addr, and contact.city.</li>
+</ul>
+
+
+
+<p>One potential drawback when using ModelDriven actions is that if you need to access some parameters in order to load the model for the ModelDriven action, you will need to call the ParametersInterceptor and/or the StaticParametersInterceptor twice (before and after the ModelDrivenInterceptor).  The first time sets all parameters on the Action, the second time sets all parameters on the model.</p>
+
+
+<h2><a name="Interceptors-ChainingInterceptor"><a name="Interceptors-Chaining"></a> ChainingInterceptor</a></h2>
+
+<p>The <b>ChainingInterceptor</b> populates the Action it is being applied to with the results of the previous action. When actions are chained together, the action being chained FROM is on the ValueStack when the next action is called. This means that when the next ActionProxy is executed, the action that is being chained TO will be placed onto the valuestack, but the old action will also be there, just down one level. This interceptor works by traversing the ValueStack to find the parameters of any objects there and sets them onto the final action.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Introduction.html

+<html>
+    <head>
+        <title>XWork - 
+        Introduction
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>XWork is a generic command pattern framework. </p>
+
+<p>The Purpose:</p>
+<ul>
+	<li>To create a generic, reusable, and extensible command pattern framework not tied to any particular usage.</li>
+</ul>
+
+
+<p>Features:</p>
+<ul>
+	<li>Flexible and customizable configuration based on a simple Configuration interface</li>
+	<li>Core command pattern framework which can be customized and extended through the use of interceptors to fit any request / response environment</li>
+	<li>Built in type conversion and action property validation using Ognl</li>
+	<li>Powerful validation framework based on runtime attributes and a validation interceptor</li>
+</ul>
+
+
+<p><b>How does XWork relate to Webwork</b></p>
+
+<p>Webwork 2.0+ is built on top of XWork and provides web-specific features that allow you to quickly build web applications using XWork's command pattern and interceptor framework.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Localization.html

+<html>
+    <head>
+        <title>XWork - 
+        Localization
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>Any action can indicate that it supports localization by implementing com.opensymphony.xwork.TextProvider.  To access a localized message, simply use one of the various getText() method calls.</p>
+
+<p>The default implementation for this is com.opensymphony.xwork.TextProviderSupport, which in turn relies on com.opensymphony.xwork.util.LocalizedTextUtil.  Any Action that extends com.opensymphony.xwork.ActionSupport will automatically gain localization support via TextProviderSupport.</p>
+
+<p>In this implementation, when you attempt to look up a message, it attempts to do the following:</p>
+
+<ul>
+	<li>Look for the message in the Action's class hierarchy.
+	<ul>
+		<li>Look for the message in a resource bundle for the class</li>
+		<li>If not found, look for the message in a resource bundle for any interface implemented by the class</li>
+		<li>If not found, get the super-class and repeat from the first sub-step unless the super-class is Object</li>
+	</ul>
+	</li>
+</ul>
+
+
+<ul>
+	<li>If not found and the Action is a ModelDriven Action, then look for the message in<br/>
+the model's class hierarchy (repeat sub-steps listed above).</li>
+</ul>
+
+
+<ul>
+	<li>If not found, look for the message in a child property.  This is determined by evaluating the message key as an OGNL expression.  For example, if the key is <em>user.address.state</em>, then it will attempt to see if "user" can be resolved into an object.  If so, repeat the entire process fromthe beginning with the object's class and <em>address.state</em> as the message key.</li>
+</ul>
+
+
+<ul>
+	<li>If not found, look for the message in the Action's package hierarchy.</li>
+</ul>
+
+
+<ul>
+	<li>If still not found, look for the message in the default resource bundles.</li>
+</ul>
+
+
+
+<h3><a name="Localization-DefaultResourceBundles.">Default Resource Bundles.</a></h3>
+
+<p>It is possible to register default resource bundles with XWork via LocalizedTextUtil.addDefaultResourceBundle().</p>
+
+<p>Message lookup in the default resource bundles is done in reverse order of their registration (i.e. the first resource bundle registered is the last to be searched). </p>
+
+<p>By default, one default resource bundle name is registered with LocalizedTextUtil &#8211; "com/opensymphony/xwork/xwork-messages" &#8211; which is bundled with the XWork jar file to provide system-level message texts.</p>
+
+
+<h3><a name="Localization-Example">Example</a></h3>
+
+<p>Given a ModelDriven Action called BarnAction where getModel() returns a Horse object, and the Horse object has the following class structure:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">interface</span> acme.test.Animal;
+class acme.test.AnimalImpl <span class="code-keyword">implements</span> Animal;
+<span class="code-keyword">interface</span> acme.test.Quadraped <span class="code-keyword">extends</span> Animal;
+class acme.test.QuadrapedImpl <span class="code-keyword">extends</span> Animal <span class="code-keyword">implements</span> Quadraped;
+class acme.test.Horse <span class="code-keyword">extends</span> QuadrapedImpl;</pre>
+</div></div>
+
+<p>Then the localization system will attempt to look up the message in the following resource bundles in this order:</p>
+
+<div class="preformatted"><div class="preformattedContent">
+<pre>acme.test.BarnAction.properties
+acme.test.Horse.properties
+acme.test.QuadrapedImpl.properties
+acme.test.Quadraped.properties
+acme.test.AnimalImpl.properties
+acme.test.Animal.properties
+acme.test.package.properties
+acme.package.properties
+</pre>
+</div></div>
+
+
+<h2><a name="Localization-MessageKeyInterpolation">Message Key Interpolation</a></h2>
+
+<p>When looking for the message, if the key indexes a collection (e.g. user.phone0) and a message for that specific key cannot be found, the general form will also be looked up (i.e. user.phone<span class="error">&#91;*&#93;</span>).</p>
+
+<h2><a name="Localization-MessageInterpolation">Message Interpolation</a></h2>
+
+<p>If a message is found, it will also be interpolated.  Anything within <b>${...}</b> will be treated as an OGNL expression and evaluated as such.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Logging.html

+<html>
+    <head>
+        <title>XWork - 
+        Logging
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>Logging in XWork is handled by <a href="http://jakarta.apache.org/commons/logging" title="Visit page outside Confluence">Commons-Logging</a>.  If Log4J is present in the classpath, logging tasks will be passed through to Log4J.</p>
+
+<p>The logger names are the class names.  The pattern used is:</p>
+<div class="code"><div class="codeContent">
+<pre class="code-java">Log log = LogFactory.getLog(ThisClass.class);</pre>
+</div></div>
+
+<p>For details on configuring commons-logging, see <a href="http://jakarta.apache.org/commons/logging/guide.html#Configuration" title="Visit page outside Confluence">&#104;ttp://jakarta.apache.org/commons/logging/guide.html#Configuration</a>. </p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Null Property Access.html

+<html>
+    <head>
+        <title>XWork - 
+         Property Access
+        </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>Null property access is a unique feature to XWork that allows object graphs to be created at runtime, saving you the headache of having to pre-initialize them.</p>
+
+
+<h3><a name="NullPropertyAccess-Simpleobjectgraphs">Simple object graphs</a></h3>
+
+<p>The feature is quite simple: <b>only</b> during the ParametersInterceptor (for WebWork this would be when http parameters are applied to an action), if an expression being set, such as "document.title", results in a NullPointerException, XWork will attempt to create the null object and try again. So in this case, if "document" is null, WebWork will construct a new Document object so that setting the title will succeed. </p>
+
+<p>This is very useful because it reduces the amount of flattening (and unflattening) you are required to do in your action classes when displaying and setting data from web pages. Rather, you can usually represent the complete object graph by just naming your input fields with well thought-out names (like "document.title"). </p>
+
+
+<h3><a name="NullPropertyAccess-Collections%2CListsandMaps">Collections, Lists and Maps</a></h3>
+
+<p>XWork extends this feature even further by offering special support for Collections, Lists and Maps.  If you are providing input for one of these interfaces, XWork can be told what type of objects they will hold and automatically populate them accordingly. What this means is that if you refer to "children0.name", XWork will automatically create a new List to hold the children and also add an empty Child object to that list, so that setting a name on the expression "children0.name" will work correctly. The same goes for maps.  </p>
+
+<p>For this to work you must tell the converters what the objects in the List or Map will be. You do this by specifying "Collection_<b>property</b> = com.acme.CollectionItem" in the conversion properties file. So if you have an action that has a "children" property that should be filled with Child objects, YourAction-conversion.properties should contain:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java">Collection_children = come.acme.Child</pre>
+</div></div>
+
+<p>For the purposes of conversion, WebWork considers Collections and Lists to be the same.   If the "children" property was declared to be a Collection, a List would be created and used.</p>
+
+
+<h3><a name="NullPropertyAccess-CustomObjects">Custom Objects</a></h3>
+
+<p>Advanced users who need to instantiate custom objects will want to extend <b>com.opensymphony.xwork.ObjectFactory</b> and override the buildBean(Class) method.  The default implementation is rather trivial:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-java"><span class="code-keyword">public</span> <span class="code-object">Object</span> buildBean(<span class="code-object">Class</span> clazz) <span class="code-keyword">throws</span> Exception {
+  <span class="code-keyword">return</span> clazz.newInstance();
+}</pre>
+</div></div>
+
+<p>Once you have your own custom ObjectFactory, you'll need to let XWork know to use it.  You do this by calling ObjectFactory.setObjectFactory(yourObjFactory).</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Ognl.html

+<html>
+    <head>
+        <title>XWork - 
+        Ognl
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>OGNL is the Object Graph Navigation Language - see <a href="http://www.ognl.org" title="Visit page outside Confluence">&#104;ttp://www.ognl.org</a> for the full documentation of OGNL. In this document we will only show the additional language features that are provided on top of the base OGNL EL. </p>
+
+
+<h2><a name="Ognl-XWorkspecificLanguageFeatures">XWork-specific Language Features</a></h2>
+
+<h3><a name="Ognl-TheValueStack">The ValueStack</a></h3>
+
+<p>The biggest addition that XWork provides on top of OGNL is the support for the ValueStack. While OGNL operates under the assumption there is only one "root", XWork's ValueStack concept requires there be many "roots". </p>
+
+<p>For example, suppose we are using standard OGNL (not using XWork) and there are two objects in the OgnlContext map: "foo" -&gt; foo and "bar" -&gt; bar and that the foo object is also configured to be the single <b>root</b> object. The following code illustrates how OGNL deals with these three situations:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-none">#foo.blah // returns foo.getBlah()
+#bar.blah // returns bar.getBlah()
+blah      // returns foo.getBlah() because foo is the root</pre>
+</div></div>
+
+<p>What this means is that OGNL allows many objects in the context, but unless the object you are trying to access is the root, it must be prepended with a namespaces such as @bar. XWork, however, is a little different...</p>
+
+<p>In XWork, the entire ValueStack is the root object in the context. But rather than having your expressions get the object you want from the stack and then get properties from that (ie: peek().blah), XWork has a special OGNL PropertyAccessor that will automatically look at the all entries in the stack (from the top down) until it finds an object with the property you are looking for.</p>
+
+<p>For example, suppose the stack contains two objects: Animal and Person. Both objects have a "name" property, Animal has a "species" property, and Person has a "salary" property. Animal is on the top of the stack, and Person is below it. The follow code fragments help you get an idea of what is going on here:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-none">species    // call to animal.getSpecies()
+salary     // call to person.getSalary()
+name       // call to animal.getName() because animal is on the top</pre>
+</div></div>
+
+<p>In the last example, there was a tie and so the animal's name was returned. Usually this is the desired effect, but sometimes you want the property of a lower-level object. To do this, XWork has added support for indexes on the ValueStack. All you have to do is:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-none">\[0\].name   // call to animal.getName()
+\[1\].name   // call to person.getName()</pre>
+</div></div>
+
+<p>Note that the ValueStack is essentially a List.  Calling [1] on the stack returns a sub-stack beginning with the element at index 1.  It's only when you call methods on the stack that your actual objects will be called.  Said another way, let's say I have a ValueStack that consists of a model and an action ([ model, action ]).  Here's how the following OGNL expressions would resolve:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-none">\[0\]      // a CompoundRoot object that contains our stack, \[model, action\]
+\[1\]      // another CompoundRoot that contains only \[action\]
+\[0\].toString() // calls toString() on the first object in the ValueStack
+               // (excluding the CompoundRoot) that supports the toString() method
+\[1\].foo  // call getFoo() on the first object in the ValueStack starting from action
+         // (excluding the CompoundRoot) that supports a getFoo() method</pre>
+</div></div>
+
+
+
+
+
+
+<h3><a name="Ognl-Accessingstaticproperties">Accessing static properties</a></h3>
+
+<p>OGNL supports accessing static properties as well as static methods. As the OGNL docs point out, you can explicetly call statics by doing the following:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-none">@some.package.ClassName@FOO_PROPERTY
+@some.package.ClassName@someMethod()</pre>
+</div></div>
+
+<p>However, XWork allows you to avoid having to specify the full package name and call static properties and methods of your action classes using the "vs" (short for ValueStack) prefix:</p>
+
+<div class="code"><div class="codeContent">
+<pre class="code-none">@vs@FOO_PROPERTY
+@vs@someMethod()
+
+@vs1@FOO_PROPERTY
+@vs1@someMethod()
+
+@vs2@BAR_PROPERTY
+@vs2@someOtherMethod()</pre>
+</div></div>
+
+<p>The important thing to note here is that if the class name you specify is just "vs", the class for the object on the top of the stack is used. If you specify a number after the "vs" string, an object's class deeper in the stack is used instead.</p>
+
+
+<h3><a name="Ognl-Thetopkeyword">The <em>top</em> keyword</a></h3>
+
+<p>XWork also adds a new keyword &#8211; <b>top</b> &#8211; that can be used to access to first object in the ValueStack.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/PrepareInterceptor.html

+<html>
+    <head>
+        <title>XWork - 
+        PrepareInterceptor
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;interceptor name=<span class="code-quote">"prepare"</span> class=<span class="code-quote">"com.opensymphony.xwork.interceptor.PrepareInterceptor"</span>/&gt;</span></pre>
+</div></div>
+
+<p>This interceptor watches for Actions that implement <b>com.opensymphony.xwork.Preparable</b> and calls the <b>prepare()</b> method on it.</p>
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Previous releases.html

+<html>
+    <head>
+        <title>XWork - 
+        Previous releases
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <ul>
+	<li>Development Version <a href="XWork 1.0.6.html" title="XWork 1.0.6">XWork 1.0.6</a></li>
+	<li>Current release - <a href="XWork 1.0.5.html" title="XWork 1.0.5">XWork 1.0.5</a></li>
+</ul>
+
+
+<ul>
+	<li>Previous releases - information on previous releases of XWork
+	<ul>
+		<li><a href="XWork 1.0.4.html" title="XWork 1.0.4">XWork 1.0.4</a></li>
+		<li><a href="XWork 1.0.3.html" title="XWork 1.0.3">XWork 1.0.3</a></li>
+		<li><a href="XWork 1.0.2.html" title="XWork 1.0.2">XWork 1.0.2</a></li>
+		<li><a href="XWork 1.0.1.html" title="XWork 1.0.1">XWork 1.0.1</a></li>
+	</ul>
+	</li>
+</ul>
+
+
+<ul>
+	<li>Dependencies</li>
+</ul>
+
+
+                    			    </td>
+		    </tr>
+	    </table>
+    </body>
+</html>

docs/wikidocs/Sample Validation Rules.html

+<html>
+    <head>
+        <title>XWork - 
+        Sample Validation Rules
+         </title>
+	    <link rel="stylesheet" href="styles/site.css" type="text/css" />
+        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+    </head>
+
+    <body>
+	    <table class="pagecontent" border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#ffffff">
+		    <tr>
+			    <td valign="top" class="pagebody">
+				    <p>In this example, we have an Action that attempts to fill the values of a User object.  The first validation file would be for a a simple Action that had a "user" property.  The second validation file is for the exact same Action if it had implemented the ModelDriven interface and exposed the User object via <b>getModel()</b> instead of <b>getUser()</b>.  Both of them uses the VisitorFieldValidator to use the User object's own validation rules to validate the User object, which can be found in the third validation file.</p>
+
+<p>Notice that the <em>short-circuit</em> attribute of the <b>field-validator</b> element is used in several places to prevent subsequent validators from running.  This is useful in preventing multiple error messages when one will do.  For example, if the value provided for the User's startDate cannot be parsed as a date, display the appropriate message and don't even bother checking that it is in the correct range.</p>
+
+<p><br clear="all" />
+SampleAction-validation.xml:</p>
+<div class="code"><div class="codeContent">
+<pre class="code-xml"><span class="code-tag">&lt;validators&gt;</span>
+    <span class="code-tag">&lt;field name=<span class="code-quote">"user"</span>&gt;</span>
+        <span class="code-tag">&lt;field-validator type=<span class="code-quote">"required"</span>  short-circuit=<span class="code-quote">"true"</span>&gt;</span>
+            <span class="code-tag">&lt;message&gt;</span>You must provide a user.<span class="code-tag">&lt;/message&gt;</span>
+        <span class="code-tag">&lt;/field-validator&gt;</span>
+        <span class="code-tag">&lt;field-validator type=<span class="code-quote">"visitor"</span>&gt;</span>
+            <span class="code-tag">&lt;param name=<span class="code-quote">"context"</span>&gt;</span>anotherContext<span class="code-tag">&lt;/param&gt;</span>
+            <span class="code-tag">&lt;message&gt;</span>user: <span class="code-tag">&lt;/message&gt;</span>
+        <span class="code-tag">&lt;/field-validator&gt;</span>