Add 'plugins/struts2-codebehind-plugin/' from commit '5b30f3ae145ce4aaf231fea299da20d4e9f90725'

git-subtree-dir: plugins/struts2-codebehind-plugin
git-subtree-mainline: f212c8fc73491de4a08db5a30225a68e924798ca
git-subtree-split: 5b30f3ae145ce4aaf231fea299da20d4e9f90725
diff --git a/apps/documentation/src/webapp/WEB-INF/web.xml b/apps/documentation/src/webapp/WEB-INF/web.xml
new file mode 100755
index 0000000..c8ca168
--- /dev/null
+++ b/apps/documentation/src/webapp/WEB-INF/web.xml
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+  <!DOCTYPE web-app PUBLIC
+	"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
+	"http://java.sun.com/dtd/web-app_2_3.dtd">
+
+<web-app>
+	<display-name>Struts Documentation</display-name>
+
+  <!-- The Welcome File List -->
+  <welcome-file-list>
+    <welcome-file>index.jsp</welcome-file>
+    <welcome-file>index.html</welcome-file>
+  </welcome-file-list>
+
+</web-app>
diff --git a/apps/documentation/src/webapp/model2.gif b/apps/documentation/src/webapp/model2.gif
new file mode 100644
index 0000000..dc40e65
--- /dev/null
+++ b/apps/documentation/src/webapp/model2.gif
Binary files differ
diff --git a/build-legacy/core/README b/build-legacy/core/README
new file mode 100644
index 0000000..32f578f
--- /dev/null
+++ b/build-legacy/core/README
@@ -0,0 +1,21 @@
+$Id$
+
+STRUTS
+======
+
+Introduction
+------------
+
+This subproject contains the source code for the "Struts" application support
+package, consisting of the following major components:
+
+- Controller servlet with action mapping technology, implementing the Model-
+  View-Controller (MVC) design pattern for web applications commonly called
+  "Model 2", with a servlet as the "front component".
+
+- Comprehensive custom tag library for building internationalized JSP pages
+  that have HTML forms which interact with JavaBeans that are managed
+  automatically by the controller servlet.
+
+For help with installing and using Struts, see the Struts User Guide.
+
diff --git a/build-legacy/core/maven.xml b/build-legacy/core/maven.xml
new file mode 100644
index 0000000..1a7e6d8
--- /dev/null
+++ b/build-legacy/core/maven.xml
@@ -0,0 +1,90 @@
+<project default="jar:jar"
+  xmlns:j="jelly:core"
+  xmlns:ant="jelly:ant">
+
+  <preGoal name="dist">
+    <attainGoal name="jar:install"/>
+  </preGoal>
+  
+  <preGoal name="xdoc:jelly-transform">
+    <attainGoal name="html2xdoc"/>
+
+    <!-- 
+      Maven FAQ PlugIn 1.2 will allow multiple faqs
+      For now, we'll just generate them from xdocs    
+    <attainGoal name="faq"/>
+    -->
+  </preGoal>
+
+  <postGoal name="dist:prepare-bin-filesystem">
+
+    <!-- Copy Instructions and Readmes -->
+    <ant:copy todir="${maven.dist.bin.assembly.dir}">
+      <ant:fileset dir=".">
+        <ant:include name="README*"/>
+        <ant:include name="LICENSE*"/>
+        <ant:include name="STATUS*"/>
+        <ant:include name="INSTALL*"/>
+      </ant:fileset>
+    </ant:copy>
+
+    <!-- Copy configuration files -->
+    <j:set var="docsDest" value="${maven.docs.dest}"/>
+    <ant:copy todir="${maven.dist.bin.assembly.dir}/conf">
+      <ant:fileset dir="./conf/share">
+        <ant:include name="*.xml"/>
+        <ant:include name="*.dtd"/>
+      </ant:fileset>
+    </ant:copy>
+  </postGoal>
+
+
+  <postGoal name="dist:prepare-src-filesystem">
+    <!-- Copy Instructions and Readmes -->
+    <ant:copy todir="${maven.dist.src.assembly.dir}">
+      <ant:fileset dir=".">
+        <ant:include name="README*"/>
+        <ant:include name="LICENSE*"/>
+        <ant:include name="STATUS*"/>
+        <ant:include name="INSTALL*"/>
+      </ant:fileset>
+    </ant:copy>
+
+    <!-- Copy configuration files -->
+    <j:set var="docsDest" value="${maven.docs.dest}"/>
+    <ant:copy todir="${maven.dist.src.assembly.dir}/conf">
+      <ant:fileset dir="./conf/share">
+        <ant:include name="*.xml"/>
+        <ant:include name="*.dtd"/>
+      </ant:fileset>
+    </ant:copy>
+  </postGoal>
+
+
+    <!--
+        Prepare Cactus webapp with necessary config files.
+    -->
+    <postGoal name="war:webapp">
+      <j:set
+       var="webapp.root"
+       
+     value="${pom.getPluginContext('maven-war-plugin').getVariable('maven.war.webapp.dir')}" />
+        <ant:echo>Copying files to ${webapp.root}</ant:echo>
+        <ant:filter token="cactus.contextURL" value="${cactus.contextURL}"/>
+        <ant:copy todir="${webapp.root}/WEB-INF/classes" filtering="on">
+            <ant:fileset dir="conf/test" includes="*.properties"/>
+        </ant:copy>
+        <ant:copy todir="${webapp.root}" filtering="off">
+            <ant:fileset dir="web/test" includes="**/*.jsp"/>
+            <ant:fileset dir="web/test" includes="**/*.txt"/>
+        </ant:copy>
+        <ant:copy todir="${webapp.root}/WEB-INF" filtering="off">
+            <ant:fileset dir="${maven.build.dir}/classes/META-INF/tlds" includes="*.tld"/>
+        </ant:copy>
+        <ant:copy file="conf/test/struts-config.xml" todir="${webapp.root}/WEB-INF" />
+        <ant:copy file="conf/test/maven-web.xml" tofile="${webapp.root}/WEB-INF/web.xml" />
+    </postGoal>
+
+  
+
+</project>
diff --git a/build-legacy/core/xdocs/acquiring.xml b/build-legacy/core/xdocs/acquiring.xml
new file mode 100644
index 0000000..6e8fdb0
--- /dev/null
+++ b/build-legacy/core/xdocs/acquiring.xml
@@ -0,0 +1,126 @@
+<?xml version="1.0"?>
+<document url="./acquiring.xml">
+
+<!--
+// ======================================================================== 78
+-->
+
+<properties>
+    <title>Acquiring - The Apache Struts Web Application Framework</title>
+</properties>
+
+<body>
+
+    <section name="Acquiring Struts" href="Acquiring">
+
+    <p>
+    The latest <em>production release</em> of Struts is
+    available in a convenient binary distribution and also with complete
+    source code. 
+    </p>
+
+        <p>
+            Apache downloads are now mirrored.
+            When you follow either the Binary or Source link,
+            please select your preferred mirror and then click on the link
+            to the <strong>Struts</strong> download.
+        </p>
+
+    <ul>
+        
+    <li>
+        <a href="http://jakarta.apache.org/site/binindex.cgi">
+        <strong>Struts Binary Distribution - Latest stable release</strong></a>
+    </li>
+
+    <li>
+        <a href="http://jakarta.apache.org/site/sourceindex.cgi">
+        <strong>Struts Source Code Distribution - Latest stable release</strong></a>
+    </li>
+    
+    </ul>
+
+    <p>
+    <strong>In addition to a Struts distribution,</strong> you will need to ensure that you have
+    downloaded and installed all of the
+    <a href="userGuide/installation.html#Prerequisites">
+    prerequisite</a> software applications. 
+    Then, follow the appropriate instructions to
+    <a href="userGuide/installation.html#Installing">
+    install and use a Struts binary distribution</a> in your web application 
+    or for
+    <a href="userGuide/installation.html#Building">
+    building Struts from the source distribution</a>.
+    </p>
+    
+</section>
+
+<section name="Nightly Builds" href="Builds">
+
+    <p>
+    For developers who are helping to develop Struts, or who just want "the 
+    latest bits", the latest development version is made available each morning. 
+    Use at your own risk!
+    </p>
+
+    <ul>
+        
+    <li>
+        Nightly builds - Download the source directly via
+        <a href="http://www.apache.org/dev/version-control.html">
+        Anonymous Subversion</a>.
+    </li>
+    
+    <li>
+        Nightly builds - Download the binary distributions from the
+       <a href="http://svn.apache.org/builds/struts/nightly/">
+        Struts nightly builds directory</a>.
+    </li>
+    
+    <li>
+        Nightly builds - Download the source distributions from the
+        <a href="http://svn.apache.org/builds/struts/nightly/src/">
+        Struts nightly build source directory</a>.
+    </li>
+    
+    </ul>
+    
+    <p>
+        If you are building Struts from source, be sure to refer to the
+        <a href="userGuide/installation.html">Installation page</a> in the
+        User Guide for prerequesites.
+        There are several JARs from the Jakarta Commons project that
+        are required to build Struts.
+    </p>
+    
+    <p>
+    If you are interested in the Tag Library Descriptor (TLD) files, 
+    they are maintained in the 
+    <a href="http://svn.apache.org/repos/asf/struts/core/trunk/conf/share/">
+    /conf/share</a> folder of the main repository. 
+    </p>
+    
+    <p>
+    Also be sure to check the
+    <a href="userGuide/release-notes.html">
+    Release Notes</a> for the nightly builds so you know what you are getting!
+    </p>
+
+    <p>
+    Access to the Subversion repository for Struts is available through both
+    <a href="http://svn.apache.org/viewcvs.cgi/struts/core/trunk/?root=Apache-SVN">web browser</a> 
+    and
+    <a href="http://www.apache.org/dev/version-control.html">
+    Subversion client</a> interfaces.
+    </p>
+
+</section>
+
+<section>
+    <p class="right">
+    Next: <a href="using.html">Using Struts</a>
+    </p>
+</section>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/announce.xml b/build-legacy/core/xdocs/announce.xml
new file mode 100644
index 0000000..4894c17
--- /dev/null
+++ b/build-legacy/core/xdocs/announce.xml
@@ -0,0 +1,266 @@
+<?xml version="1.0"?>
+<document>
+
+  <properties>
+    <title>Announcements</title>
+  </properties>
+
+<body>
+
+<section name="Announcements">
+
+    <h4 id="a20030630">30 Jun 2003 - Struts 1.1 Final released</h4>
+    <p>
+        The Struts team is proud, and extremely pleased, to announce the Final
+        release of Struts 1.1. This release includes significant new
+        functionality, as well as numerous fixes for bugs which were reported
+        against the previous release, and supersedes the earlier 1.0.2 version
+        as the latest official release of Struts from the Apache Software
+        Foundation.
+    </p>
+    <p>The binary distribution is available at: <a href=
+    "http://www.apache.org/dist/jakarta/struts/binaries/">
+    http://www.apache.org/dist/jakarta/struts/binaries/</a> </p>
+    <p>and the source distribution is available at: <a href=
+    "http://www.apache.org/dist/jakarta/struts/source/">
+    http://www.apache.org/dist/jakarta/struts/source/</a></p>
+    <p>In addition, the library distribution, which contains updated binaries
+       without the sample applications, is available at: </p>
+    <p><a href="http://www.apache.org/dist/jakarta/struts/library/">
+    http://www.apache.org/dist/jakarta/struts/library/</a> </p>
+    <p>Details of the changes in this release are available in the Release
+    Notes,which can be found here: </p>
+    <p><a href=
+    "http://jakarta.apache.org/struts/userGuide/release-notes-1.1.html">
+    http://jakarta.apache.org/struts/userGuide/release-notes-1.1.html</a> </p>
+    <hr/>
+
+    <h4 id="a20030223">23 Feb 2003 - Struts 1.1 Release Candidate 1 Released</h4>
+    <p>
+        The Struts team is proud to announce the release of Struts 1.1 Release
+        Candidate 1. This release includes some new functionality, as well as
+        fixes for a number of bugs which were reported against earlier versions.
+        The Struts Team believes that this release is ready for prime time, hence
+        its designation as a release candidate.
+    </p>
+    <p>
+        The binary distribution is available at:
+    </p>
+    <p>
+        <a href="http://www.apache.org/dist/jakarta/struts/binaries/">
+        http://www.apache.org/dist/jakarta/struts/binaries/</a>
+    </p>
+    <p>
+        and the source distribution is available at:
+    </p>
+    <p>
+        <a href="http://www.apache.org/dist/jakarta/struts/source/">
+        http://www.apache.org/dist/jakarta/struts/source/</a>
+    </p>
+    <p>
+        In addition, the library distribution, which contains updated binaries
+        without the sample applications, is available at:
+    </p>
+    <p>
+        <a href="http://www.apache.org/dist/jakarta/struts/library/">
+        http://www.apache.org/dist/jakarta/struts/library/</a>
+    </p>
+    <p>
+        Details of the changes in this release are available in the Release
+        Notes, which can be found here:
+    </p>
+    <p>
+        <a href="http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc1.html">
+        http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc1.html</a>
+    </p>
+    <hr/>
+
+    <h4 id="S20021231">31 Dec 2002 - Struts 1.1 Beta 3 Released</h4>
+    <p>The Struts team is proud to announce the release of Struts 1.1 Beta 3. This
+    release includes significant new functionality, while retaining full
+    backwards compatibility with earlier versions of Struts. It also
+    incorporates fixes for a number of bugs which were reported against earlier
+    versions.
+    </p>
+    <p>
+    The binary distribution is available at:
+    </p>
+    <p>
+    <a href="http://www.apache.org/dist/jakarta/struts/binaries/">
+    http://www.apache.org/dist/jakarta/struts/binaries/</a>
+    </p>
+    <p>
+    and the source distribution is available at:
+    </p>
+    <p>
+    <a href="http://www.apache.org/dist/jakarta/struts/source/">
+    http://www.apache.org/dist/jakarta/struts/source/</a>
+    </p>
+    <p>
+    In addition, the library distribution, which contains updated binaries
+    without the sample applications, is available at:
+    </p>
+    <p>
+    <a href="http://www.apache.org/dist/jakarta/struts/library/">
+    http://www.apache.org/dist/jakarta/struts/library/</a>
+    </p>
+    <p>
+    Details of the changes in this release are available in the Release Notes,
+    which can be found here:
+    </p>
+    <p>
+    <a href="http://jakarta.apache.org/struts/userGuide/release-notes-1.1-b3.html">
+    http://jakarta.apache.org/struts/userGuide/release-notes-1.1-b3.html</a>
+    </p>
+    <hr/>
+
+    <h4 id="a20020813">12 Aug 2002 - Struts 1.1 Beta 2 Released</h4>
+    <p>The Struts team is proud to announce the release of Struts 1.1 Beta 2. This
+    release includes significant new functionality, while retaining full
+    backwards compatibility with earlier versions of Struts. It also
+    incorporates fixes for a number of bugs which were reported against earlier
+    versions.
+    </p>
+    <p>
+    The binary distribution is available at:
+    </p>
+    <p>
+    <a href="http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/">http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/</a>
+    </p>
+    <p>
+    and the source distribution is available at:
+    </p>
+    <p>
+    <a href="http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/src/">http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/src/</a>
+    </p>
+    <p>
+    In addition, the library distribution, which contains updated binaries
+    without the sample applications, is available at:
+    </p>
+    <p>
+      http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b2/lib/
+    </p>
+    <p>
+    Details of the changes in this release are available in the Release Notes,
+    which can be found here:
+    </p>
+    <p>
+      http://jakarta.apache.org/struts/userGuide/release-notes-1.1-b2.html
+    </p>
+    <hr/>
+
+    <h4 id="a20020319">19 Mar 2002 - Struts 1.1 Beta 1 Released</h4>
+    <p>
+    The Struts team announces the release of Struts 1.1 Beta 1. This release
+    includes substantial new functionality, while retaining full backwards
+    compatibility with earlier versions of Struts. It also incorporates fixes
+    for a number of bugs which were reported against earlier versions.
+    </p>
+    <p>
+    The binary distribution for this release is available
+    <a href="http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b1/">
+    <strong>here</strong></a>
+    and the source distribution
+    is available
+    <a href="http://jakarta.apache.org/builds/jakarta-struts/release/v1.1-b1/src/">
+    <strong>here</strong></a>.
+    In addition, a library distribution, which consists of a minimal
+    binary distribution, without sample web applications or additional code, is
+    available
+    <a href="http://www.apache.org/dist/jakarta/jakarta-struts/release/v1.1-b1/lib/">
+    <strong>here</strong></a>.
+    </p>
+    <hr/>
+
+    <h4 id="a20020211">11 Feb 2002 - Struts 1.0.2 Released</h4>
+    <p>
+    The Struts team announces the release of Struts 1.0.2. This release is a
+    bug fix only release, which fixes a compatibility problem inadvertently introduced
+    with the previous 1.0.1 release.
+    </p>
+    <p>
+    The binary distribution for this release is available
+    <a href="http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/">
+    <strong>here</strong></a>
+    and the source distribution
+    is available
+    <a href="http://jakarta.apache.org/builds/jakarta-struts/release/v1.0.2/src/">
+    <strong>here</strong></a>.
+    In addition, a library distribution, which consists of a minimal
+    binary distribution, without sample web applications or additional code, is
+    available
+    <a href="http://www.apache.org/dist/jakarta/jakarta-struts/release/v1.0.2/lib/">
+    <strong>here</strong></a>.
+    </p>
+    <hr/>
+
+    <h4 id="a20020112">12 Jan 2002 - Struts 1.0.1 Released</h4>
+    <p>
+      The Struts team is proud to announce the release of Struts 1.0.1. This
+      release is primarily a bug fix release, which fixes a number of known
+      problems with the previous 1.0 release.
+    </p>
+    <p>
+      The binary distribution for this release is available
+      <a href="http://www.apache.org/dist/jakarta/jakarta-struts/release/v1.0.1/">here</a>
+      and the source distribution is available
+      <a href="http://www.apache.org/dist/jakarta/jakarta-struts/release/v1.0.1/src/">here</a>.
+      In addition, a library distribution, which consists of a minimal binary distribution,
+      without sample web applications or additional code, is available
+      <a href="http://www.apache.org/dist/jakarta/jakarta-struts/release/v1.0.1/lib/">here</a>.
+    </p>
+    <hr/>
+
+
+    <h4 id="a20010615">15 Jun 2001 - Struts 1.0 Released</h4>
+
+<p>
+The production release of Struts 1.0, an open source framework for building Web applications, is now available for download at jakarta.apache.org. Struts encourages application architectures based on the Model-View-Controller (MVC) pattern and provides services common
+to most Web applications. Struts helps developers deploy products that are reliable, scaleable, and easier to maintain.
+</p>
+
+<p>
+The Struts framework offers services in three primary areas:
+</p>
+
+<p>
+* A controller servlet to dispatch requests to specific Action classes (provided by the application developer).<br/>
+* JSP custom tags to help developers create interactive form-based applications.<br/>
+* Utility classes for XML parsing, automatic JavaBean population, and internationalization of prompts and messages.
+</p>
+
+<p>
+Struts' support for internationalization builds on top of the Java Locale API, and have made it a popular choice for applications worldwide. Struts contributors include developers from Australia, France, Russia, and other parts of the globe.
+</p>
+
+<p>
+In addition to the Struts official distribution, several third-party libraries are already available, which offer enhanced support for JSP templates, HTML form validation, and automatic JavaBean creation. Struts has also been integrated with the Expresso Framework distributed by
+JCorporate Ltd. (jcorporate.com).
+</p>
+
+<p>
+Struts can be used with a J2EE Application server to deploy distributed applications, but will run under any compliant Servlet container (Servlet API 2.2+, JSP 1.1+), including Tomcat 3.2 or later. In fact, Struts is already used as an informal compliance test for Java Servlet
+containers and J2EE Application servers
+</p> 
+
+<p>
+The Struts project was founded in May 2000 by Craig McClanahan. McClanahan is also the lead developer of Tomcat 4.0, Sun's reference implementation for Java Servlet and ServerPage containers. Both Tomcat and Struts are open source available under the Apache Software License,
+and may be downloaded at jakarta.apache.org.
+</p>
+
+<p>
+Twenty-six independent developers contributed to the creation of Struts 1.0, with the help of over 1300 subscribers to the Struts mailing lists.<br/>
+</p>
+
+<hr />
+
+</section>
+
+    <section>
+       <p class="right">Next:
+       <a href="userGuide/index.html">User and Developer Guides</a>
+       </p>
+    </section>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/example.xml b/build-legacy/core/xdocs/example.xml
new file mode 100644
index 0000000..1c6968b
--- /dev/null
+++ b/build-legacy/core/xdocs/example.xml
@@ -0,0 +1,112 @@
+<?xml version="1.0"?>
+<document>
+
+  <properties>
+    <title></title>
+  </properties>
+
+  <meta name="keyword" content="jakarta, java"/>
+
+<body>
+
+<section name="Section 1">
+<p>
+This is section 1.
+</p>
+
+<table>
+<tr>
+    <td>This is a table</td><td>This is a table</td>
+</tr>
+<tr>
+    <td>This is a table</td><td>This is a table</td>
+</tr>
+</table>
+
+<ul>
+    <li>This is an unordered list.</li>
+</ul>
+
+</section>
+
+<section name="Section 2">
+<p>
+This is section 2.
+</p>
+
+<ol>
+    <li>This is an ordered list.</li>
+</ol>
+</section>
+
+<section name="Section 3">
+<p>
+This is section 3.
+</p>
+
+<source>
+    Anything within this tag is rendered as a "box"
+    with blue lines and <pre></pre> tags around it.
+</source>
+
+    <subsection name="Subsection of Section 3">
+    <p>
+        This is the subsection 3.
+    </p>
+
+    <source><![CDATA[      
+    <?xml version="1.0" encoding="ISO-8859-1" ?>
+    <!DOCTYPE struts-config PUBLIC
+              "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
+              "http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd">
+    <struts-config>
+        <form-beans>
+            <form-bean
+                name="logonForm"
+                type="app.LogonForm"/>
+        </form-beans>
+        <action-mappings>
+            <action
+                path="/Welcome"
+                forward="/pages/Welcome.jsp"/>
+            <action
+                path="/Logon"
+                forward="/pages/Logon.jsp"/>
+            <action
+                path="/LogonSubmit"
+                type="app.LogonAction"
+                name="logonForm"
+                scope="request"
+                validate="true"
+                input="/Logon.do">
+                <forward
+                    name="success"
+                    path="/Welcome.do"/>
+                <forward
+                    name="failure"
+                    path="/Logon.do"/>
+            </action>
+            <action
+                path="/Logoff"
+                type="app.LogoffAction">
+                <forward
+                    name="success"
+                    path="/Welcome.do"/>
+            </action>
+        </action-mappings>
+        <message-resources parameter="resources.application"/>
+    </struts-config>
+    ]]></source>
+
+
+    </subsection>
+</section>
+
+<footer>
+    <a href="http://sourceforge.net/projects/ctecl">
+      <img src="http://sourceforge.net/sflogo.php?group_id=72748" border="0" alt="sf logo"/>
+    </a>
+</footer>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/faq.fml b/build-legacy/core/xdocs/faq.fml
new file mode 100644
index 0000000..5462ed7
--- /dev/null
+++ b/build-legacy/core/xdocs/faq.fml
@@ -0,0 +1,161 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<faqs title="Frequently Asked Questions">
+
+<!-- 
+    Maven FAQ PlugIn 1.2 will allow multiple faqs but, for now, we'll just 
+    generate them from xdocs. This file is just an example of a FAQ file for
+    the FAQ plug-in and is not maintained.
+-->     
+      
+  <part id="general">
+    <title>General</title>
+
+    <faq id="why">
+      <question>Why do we need Struts?</question>
+      <answer>
+        Java technologies give developers a serious boost when creating and 
+        maintaining applications to meet the demands of today's public Web 
+        sites and enterprise intranets. Struts combines Java Servlets, Java 
+        ServerPages, custom tags, and message resources into a unified 
+        framework. The end result is a cooperative, synergistic platform, 
+        suitable for development teams, independent developers, and everyone 
+        in between.
+      </answer>
+    </faq>
+
+    <faq id="how">
+      <question>How does Struts work?</question>
+      <answer>
+        Java Servlets are designed to handle requests made by Web browsers. 
+        Java ServerPages are designed to create dynamic Web pages that can turn
+         billboard sites into live applications. Struts uses a special Servlet 
+         as a switchboard to route requests from Web browsers to the appropriate 
+         ServerPage. This makes Web applications much easier to design, create, 
+         and maintain.
+      </answer>
+    </faq>
+    
+    <faq id="compatible">
+      <question>Is Struts compatible with other Java technologies?</question>
+      <answer>
+        Yes. Struts is committed to supporting industry standards. Our lead 
+        developer is a member of <a id="http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html">JSR052</a>, 
+        Sun's Expert group for developing a standard library of custom JSP 
+        tags. A primary design criteria is that Struts must be compatible with 
+        Sun's J2EE platform for corporate enterprises. In fact, Struts really 
+        acts as an integrator of Java technologies, so that they can be used in 
+        the &quot;real world&quot;.
+      </answer>
+    </faq>
+
+    <faq id="who">
+      <question>Who wrote Struts?</question>
+      <answer>
+	    <p>Struts was created by Craig R. McClanahan, and donated to the Apache 
+	    Software Foundation in May 2000. Craig is the primary developer of both 
+	    Struts and <a id="http://jakarta.apache.org/tomcat/index.html">Tomcat 4</a>, 
+	    the basis for the official reference implementation for a servlet 2.3 
+	    and JSP 1.2 container. With stable releases of Struts and Tomcat 4 in 
+	    circulation, Craig is now the Specification Lead for 
+	    <a id="http://jcp.org/jsr/detail/127.jsp">JavaServer Faces (JSR-127)</a>, 
+	    and is the Web Layer Architect for the Java2 Enterprise Edition (J2EE) 
+	    platform as a whole.</p>
+	    <p>There are now many active committers to the Struts project, working 
+	    cooperatively from around the globe. Other Java developers are invited 
+	    to <a id="helping.html#contribute">contribute to the project</a>. 
+	    Struts is an <a id="http://jakarta.apache.org/">Apache Jakarta</a>  
+	    project, with the common mission to &quot;provide commercial-quality 
+	    server solutions based on the Java Platform that are developed in an 
+	    open and cooperative fashion&quot;. All told, 17 individual developers 
+	    and committers contributed to the Struts 1.0 codebase.</p>
+      </answer>
+    </faq>
+
+    <faq id="struts">
+      <question>Why is it called Struts?</question>
+      <answer>
+        It's a reference to struts in the architectural sense, a reminder of 
+        the nearly invisible pieces that hold up buildings, houses, and bridges.
+      </answer>
+    </faq>
+    
+    <faq id="license">
+      <question>How is Struts licensed?</question>
+      <answer>
+        Struts is copyrighted software available under a 
+        &quot;free-to-use-license&quot; by The Apache Software Foundation. 
+        The license appears at the head of every source code file. A reference
+        copy of the license is available 
+        <a href="http://www.apache.org/LICENSE-1.1">here</a>.
+      </answer>
+    </faq>
+
+    <faq id="usage">
+      <question>Can Struts be used in a commercial product?</question>
+      <answer>
+        <p>Yes. The only requirements you must meet are those listed in the 
+        Apache Software Foundation license, which is included at the top of 
+        each source file and in the file LICENSE in the top-level directory 
+        of the distribution.</p>
+        <p>In addition, <a id="helping.html#bugs">contributions of patches, 
+        improved code, new features,</a> or even just requests for features 
+        are also welcome.</p>
+      </answer>
+    </faq>
+    
+    <faq id="credits">
+      <question>Do I have to credit Struts on my own website?</question>
+      <answer>
+        You need to credit Struts if you <strong>redistribute your own framework</strong>
+        based on Struts	for other people to use. (See the 
+        <a id="http://www.apache.org/LICENSE">Apache License</a> for details.)
+        But you do <strong>not</strong> need to credit Struts just because your
+        web application utilizes the framework.	It's the same situation as using 
+        the Apache HTTPD server or Tomcat. Not required if its just running 
+        your web site. Required if you've used the source code to create your 
+        own server that you are redistributing to other people.      
+      </answer>
+    </faq>
+    
+    <faq id="where">
+      <question>Where can I get a copy of Struts?</question>
+      <answer>
+        The best place to download Struts is at 
+        <a id="http://jakarta.apache.org/struts/">jakarta.apache.org/struts</a>. 
+        The nightly builds are very stable, and recommended as the best place 
+        to start today.
+      </answer>
+    </faq>
+    
+    <faq id="install">
+      <question>How do I install Struts?</question>
+      <answer>
+        <p>To develop applications with Struts, you can usually just add the
+        Struts JAR file	to your Java development environment. You can then 
+        start using the Struts classes as part of your own application. 
+        A blank Struts application (in the <code>webapps</code> directory, 
+        open <code>struts-blank.war</code>)	is provided, which you can just 
+        copy to get a quick-start on your own brainchild.</p>
+        <p>Since the full source code for Struts is available, we also provide 
+        <a id="../userGuide/installation.html">complete instructions</a> for
+        compiling your own Struts JAR from scratch. (This is actually easier 
+        than it looks!)</p>
+        <p>Your Struts application can usually be deployed using a standard WAR 
+        file. In most cases, you simply deposit the WAR file on your application 
+        server, and it is installed	automatically. If not, step-by-step 
+        installation instructions for 
+        <a id="../userGuide/installation.html#Containers">various servlet 
+        containers</a> are available.</p>
+      </answer>
+    </faq>
+    
+  </part>
+
+  <!--
+    <faq id="">
+      <question></question>
+      <answer>
+      </answer>
+    </faq>
+  -->
+</faqs>
diff --git a/build-legacy/core/xdocs/faqs/actionForm.xml b/build-legacy/core/xdocs/faqs/actionForm.xml
new file mode 100644
index 0000000..4084e91
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/actionForm.xml
@@ -0,0 +1,285 @@
+<?xml version="1.0"?>
+
+<document url="./actionForm.xml">
+
+ <properties>
+  <title>Building an ActionForm</title>
+ </properties>
+
+<body>
+<section href="actionForm" name="How to Build an Action Form"/>
+           
+<section href="login" name="Creating a Login Form">
+
+    <p>
+    This is a simple example of a login form to illustrate how Struts
+    makes dealing with forms much less painful than using straight HTML
+    and standard JSP facilities.  
+    Consider the following page (based on the example MailReader application 
+    included  with Struts) named <code>logon.jsp</code>:
+    </p>
+
+<hr/>
+
+<pre><code><![CDATA[
+<%@ page language="java" %>
+<%@ taglib  uri="/WEB-INF/struts-html.tld" prefix="html" %>
+<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
+
+<html:html>
+<head>
+<title>
+    <bean:message key="logon.title"/>
+</title>
+</head>
+
+<body bgcolor="white">
+
+<html:errors/>
+
+<html:form action="/logon" focus="username">
+<table border="0" width="100%">
+    <tr>
+        <th class="right">
+            <bean:message key="prompt.username"/>
+        </th>
+        <td class="left">
+            <html:text  property="username" size="16"/>
+        </td>
+    </tr>
+    <tr>
+        <th class="right">
+            <bean:message key="prompt.password"/>
+        </th>
+        <td class="left">
+            <html:password property="password" size="16"/>
+        </td>
+    </tr>
+    <tr>
+        <td class="right">
+            <html:submit>
+                <bean:message key="button.submit"/>
+            </html:submit>
+        </td>
+        <td class="right">
+            <html:reset>
+                <bean:message key="button.reset"/>
+            </html:reset>
+        </td>
+    </tr>
+</table>
+
+</html:form>
+</body>
+</html:html>
+]]></code></pre>
+
+<hr/>
+
+    <p>
+    The following items illustrate the key features of form handling in Struts,
+    based on this example:
+    </p>
+
+    <ul>
+
+        <li>
+        The <code>taglib</code> directive tells the JSP page compiler where to
+        find the <em>tag library descriptor</em> for the Struts tag library.  
+        In this case, we are using <code>bean</code> as the prefix that 
+        identifies tags from the struts-bean library, and "html" as the prefix  
+        that identifies tags from the struts-html library.  
+        Any desired prefix can be used.
+        </li>
+          
+        <li>
+        This page uses several occurrences of the
+        <strong>message</strong> tag to look up internationalized
+        message strings from a <code>MessageResources</code> object containing
+        all the resources for this application.  
+        For this page to work, the following message keys must be defined in 
+        these resources:
+          
+        <ul>
+        
+            <li>
+            <strong>logon.title</strong> - Title of the logon page
+            </li>
+
+            <li>
+            <strong>prompt.username</strong> - A "Username:" prompt string
+            </li>
+
+            <li>
+            <strong>prompt.password</strong> - A "Password:" prompt string
+            </li>
+
+            <li>
+            <strong>button.submit</strong> - "Submit" for the button label
+            </li>
+
+            <li>
+            <strong>button.reset</strong> - "Reset" for the button label
+        </li>
+        
+        </ul>
+
+        When the user logs on, the application can store a <code>Locale</code>
+        object in the user's session.  
+        This <code>Locale</code> will be used to select messages in the 
+        appropriate language.  
+        This makes it easy to implement giving the user an option to switch 
+        languages -- simply change the stored <code>Locale</code> object, and 
+        all messages are switched automatically.
+        </li>
+          
+        <li>
+        The <strong>errors</strong> tag displays any error messages that have been 
+        stored by a business logic component, or nothing if no errors have been 
+        stored.  
+        This tag will be described further below.
+        </li>
+          
+        <li>
+        The <strong>form</strong> tag renders an HTML <code>&lt;form&gt;</code> element, 
+        based on the specified attributes.
+        It also associates all of the fields within this form with a 
+        <code>ActionForm</code> bean 
+        [<code>org.apache.struts.action.ActionForm</code>].
+        The tag looks up the <code>/logon</code> action mapping in the Struts
+        configuration.
+        The <code>logon</code> mapping tells the tag that the form bean is
+        stored in the session context under the key <code>logonForm</code>.
+        The Struts developer provides the Java implementation of the 
+        ActionForm bean, subclassing the Struts class <code>ActionForm</code>
+        (see <a href="../userGuide/building_controller.html#action_form_classes">Building
+        Controller</a> components).
+        This bean is used to provide initial values for all of the input
+        fields that have names matching the property names of the bean.
+        If an appropriate bean is not found, a new one will be created
+        automatically, using the Java class name specified through the 
+        action mapping.
+        </li>
+
+        <li>
+        The form bean can also be specified in the tag by providing
+        <code>name</code> and <code>type</code> attributes. But most often,
+        everything is specified in the
+        <a href="../userGuide/building_controller.html#config">Struts Configuration 
+        File</a>.
+        </li>
+
+        <li>
+        The <strong>text</strong> tag renders an HTML <code>&lt;input&gt;</code> 
+        element of type "text".  
+        In this case, the number of character positions to occupy on the 
+        browser's screen has been specified as well. 
+        When this page is executed, the current value of the 
+        <code>username</code> property of the corresponding bean (that is, 
+        the value returned by <code>getUsername</code>).
+        </li>
+
+        <li>
+        The <strong>password</strong> tag is used similarly.
+        The difference is that the browser will echo asterisk characters,
+        instead of the input value, as the user types their password.
+        </li>
+
+        <li>
+        The <strong>submit</strong> and<strong>reset</strong> tags generate the corresponding
+        buttons at the bottom of the form.  
+        The text labels for each button are created using message tags,
+        as with the prompts, so that these values are internationalized.
+        </li>
+          
+    </ul>
+
+    <p>
+    Handling multipart forms is also easy.  
+    Obviously when you create a multipart form you're creating a form that  
+    has at least one input of type "file".  
+    The first step to creating a multipart form is to utilize the struts-html 
+    taglib to create the presentation page:
+    </p>
+
+<hr/>
+
+<pre><code><![CDATA[
+<%@page language="java">
+<%@taglib 
+    uri="/WEB-INF/struts-html.tld"
+   prefix="html">
+
+<html:form action="uploadAction.do" enctype="multipart/form-data">
+
+    Please Input Text: <html:text property="myText">
+    Please Input The File You Wish to Upload: <html:file property="myFile">
+   
+   <html:submit />
+
+</html:form>
+]]></code></pre>
+
+<hr/>
+
+    <p>
+    The next step is to create your ActionForm bean:
+    </p>
+
+
+<hr/>
+
+<pre><code><![CDATA[
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
+import org.apache.struts.action.ActionForm;
+import org.apache.struts.action.ActionMapping;
+import org.apache.struts.upload.FormFile;
+
+public class UploadForm extends ActionForm {
+
+    protected String myText;
+    protected FormFile myFile;
+    
+    public void setMyText(String text) {
+        myText = text;
+    }
+    
+    public String getMyText() {
+        return myText;
+    }
+    
+    public void setMyFile(FormFile file) {
+        myFile = file;
+    }
+    
+    public FormFile getMyFile() {
+        return myFile;
+    }
+
+}
+]]></code></pre>
+
+<hr/>
+
+    <p>
+    Look at the Javadocs for 
+    <code><a href="../api/org/apache/struts/upload/FormFile.html">
+    FormFile</a></code> to see the methods it exposes to manipulate files in 
+    file uploading.
+    Also look at the Javadocs for
+    <a href="../api/org/apache/struts/action/ActionServlet.html">
+    ActionServlet</a> and
+    <a href="../api/org/apache/struts/action/ActionMapping.html">
+    ActionMapping</a> for the various parameters you can specify to change 
+    how files are uploaded.  
+    Basically in your <code>execute</code> method in your action class you 
+    would call <code>((UploadForm) form).getMyFile()</code> to retrieve the 
+    FormFile and do what you want with it.
+    </p>
+
+</section>
+
+ </body>
+</document>
+
diff --git a/build-legacy/core/xdocs/faqs/apps.xml b/build-legacy/core/xdocs/faqs/apps.xml
new file mode 100644
index 0000000..2606a86
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/apps.xml
@@ -0,0 +1,143 @@
+<?xml version="1.0"?>
+<document url="./apps.xml">
+<properties>
+<title>Building Applications</title>
+</properties>
+<body>
+<section name="How to Build Applications" href="building_apps"/>
+<section href="intro" name="About This Document">
+<p>
+This document outlines one possible sequence of development steps that can be followed to create a
+Struts application.  It is not intended as a complete description of each
+referenced development activity.  More detailed documentation is available
+elsewhere and is referenced by "(more...)" links where possible.
+</p>
+</section>
+
+<section href="caveats" name="Caveats">
+<ol>
+<li>Requirements development and design are outside of the scope of this  document.</li>
+<li>For help installing Struts, see the <a href="../userGuide/installation.html">Getting Started</a> chapter.</li>
+<li>There are many other ways to approach Struts development and there are many
+    other features available besides the ones discussed below. This document
+    outlines only one way to get started.</li>
+<li>This document focuses on form/data centric applications, but may also work with
+    other types of applications.</li>
+<li>This material was written for Struts 1.1 (beta 2).</li>
+</ol>
+</section>
+
+<section href="overview" name="Overview">
+<ol>
+<li>Implement data entry forms as JSP files.</li>
+<li>Implement one or more <code>ActionForm</code> descendents to buffer data
+    between JSPs and Actions.</li>
+<li>Create an XML document that defines the validation rules for your
+    application.</li>
+<li>Implement one or more <code>Action</code> descendents to respond form
+    submissions.</li>
+<li>Create <code>struts-config.xml</code> to associate forms with
+    actions.</li>
+<li>Create or update <code>web.xml</code> to reference
+    <code>ActionServlet</code>, taglibs used by Struts.</li>
+<li>Parallel Tasks
+<ol>
+<li>Building</li>
+<li>Unit Testing</li>
+<li>Deployment</li>
+</ol>
+</li>
+</ol>
+</section>
+
+<section href="details" name="Details">
+<ol>
+<li>Implement data entry forms as JSP files.
+<ol>
+<li>Use elements from the <code>html</code> taglib
+    to define the form elements. <a href="../userGuide/struts-html.html">
+    (more...)</a></li>
+<li>Use <code>message</code> and other elements from the <code>bean</code>
+    taglib to define the labels and other static text of the form. 
+    <a href="../userGuide/struts-bean.html">(more...)</a>
+<ol>
+<li>Create and maintain a properties file of the text elements
+    to be displayed. <a href="../userGuide/preface.html#resources">(more...) 
+    </a></li>
+</ol>
+</li>
+<li>Use <code>property</code> attributes to link form fields to 
+    <code>ActionForm</code> instance variables.</li>
+</ol>
+</li>
+<li>Implement one or more <code>ActionForm</code> descendents
+    to buffer data between JSPs and Actions.
+<ol>
+<li>Create get/set pairs that correspond to the property names
+    in your related JSP form. Example:
+<pre>&lt;html:text property="city" /&gt;</pre>
+    needs:
+<pre>getCity() and setCity(String c)</pre>
+</li>
+<li>When needed, create a <code>reset</code> method
+    that sets the fields of the <code>ActionForm</code> to their default values. Most ActionForms do not need to do this.</li>
+</ol>
+</li>
+<li>Create an XML document that defines the validation rules for your
+    application.</li>
+<li>Implement one or more <code>Action</code> descendents
+    to respond to form submissions.
+<ol>
+<li>Descend from DispatchAction or LookupDispatchAction if you
+    want one class to handle more than one kind of event (example: one Action
+    to handle 'insert', 'update' and 'delete' events, using a different "surrogate" execute method for each). <a href="http://husted.com/struts/tips/002.html">(more...)</a></li>
+<li>Use the <code>execute</code> method
+    (or its surrogates) of your Action class to interface with objects in your
+    application responsible for database interaction, such as EJBs, etc.
+    <!-- [:TODO: find good doc to link to] -->
+</li>
+<li>Use the return value of the <code>execute</code> method
+    (or its surrogates) direct the user interface to the appropriate next page.
+<!-- [:TODO: find good doc to link to] -->
+</li>
+</ol>
+</li>
+<li>Create <code>struts-config.xml</code> to
+    associate forms with actions. The file minimally needs:</li>
+<li>Create or update <code>web.xml</code> to
+    reference <code>ActionServlet</code>, taglibs used by Struts. <a href="../userGuide/configuration.html#dd_config"> (more...)</a></li>
+<li>Parallel Tasks
+<ol>
+<li>Building
+<ol>
+<li>Use Ant. It can compile, create WAR file, perform XSLT
+   transformations, run unit tests, interact with version control systems,
+   clean up, etc. <a href="http://jakarta.apache.org/ant"> (more...)</a></li>
+<li>Create and use build script incrementally, as you create
+    files that need to be copied, compiled, etc. </li>
+</ol>
+</li>
+<li>Unit Testing
+<ol>
+<li>Unit test normal java beans with JUnit. <a href="http://www.junit.org"> (more...)</a></li>
+<li>Unit test JSP, taglibs and conventional servlet components
+    with Cactus. <a href="http://jakarta.apache.org/cactus"> (more...)</a></li>
+<li>Unit test Action servlets with StrutsTestCase. <a href="http://strutstestcase.sourceforge.net"> (more...)</a></li>
+<li>Add all unit tests to the build script as a separate
+    target. This target should use the <code>junit</code> tag to launch each TestCase descendent. <a href="http://jakarta.apache.org/ant/manual/OptionalTasks/junit.html"> (more...)</a></li>
+</ol>
+</li>
+<li>Deployment
+<ol>
+<li>Build script should create a war file containing the
+    files developed above, along with files that make up the Struts framework.
+    <!-- [:TODO: describe this further, look for doc to link to] -->
+</li>
+</ol>
+</li>
+</ol>
+</li>
+</ol></section>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/faqs/database.xml b/build-legacy/core/xdocs/faqs/database.xml
new file mode 100644
index 0000000..a2be42a
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/database.xml
@@ -0,0 +1,291 @@
+<?xml version="1.0"?>
+
+<document url="./database.xml">
+
+ <properties>
+  <title>Accessing a Database</title>
+ </properties>
+
+<body>
+<section href="actionForm" name="How to Access a Database"/>
+
+<section name="Accessing a Database" href="database">
+
+    <p>
+    The best thing is use the Action as a thin adaptor between the
+    web/presentation-tier and your business classes (including those that
+    access a database).
+    </p>
+
+    <p>
+    So you first design a business API that uses plain Java classes.
+    The best thing is to use objects that take ordinary Java types and return
+    a JavaBean or collection of JavaBeans.
+    The Action then calls these objects and passes the result back to the
+    web/presentation tier.
+    </p>
+
+    <p>
+    A common approach is to create an Action class for each of the business
+    API methods/classes that you need to call.
+    Ideally, all the database access code should be encapsulated in the
+    business API classes, so Struts doesn't know what persistent layer you
+    are using (or even if there is a persistence layer).
+    It just passes a key or search String and gets back a bean or collection
+    of beans.
+    This lets you use the same business API classes in other environments,
+    and also to run unit tests against your business API outside of Struts or
+    a HTTP environment.
+    </p>
+
+    <p>
+    To get started, it's simplest to setup a 1:1 correspondence between the
+    Actions and the entry-points to your business API.
+    As you gain experience, you will find ways to combine your Actions, say
+    by using the DispatchAction.
+    It's even possible to use a single "framework" Action to call all of your
+    business classes, as is done with Scaffold ProcessAction in the contrib
+    folder.
+    Using fewer Actions does require a deeper understanding of how Struts and
+    MVC frameworks operate.
+    Don't hesitate to err on the side of creating more Actions at first.
+    The Struts configuration makes it easy to refactor your Actions later,
+    since you can change the Action type without changing anything else in the
+    application.
+    </p>
+
+    <p>
+    Ideally, the business logic layer should encapsulate the data access
+    details, including acquiring a database connection.
+    However, some application designs expect that the caller be able to provide a
+    database connection or DataSource instance.
+    When this is the case, the Struts DataSource manager can make it easy for
+    your Action to produce these resources on demand.
+    </p>
+
+    <p>
+    The Struts DataSource manager is configured as an element in the
+    <a href="../userGuide/configuration.html#data-source_config">
+    Struts configuration file</a> (struts-config.xml).
+    The manager can be used to deploy any connection pool that implements the
+    <code>javax.sql.DataSource</code> interface and is configurable totally
+    from JavaBean properties.
+    If your DBMS or container provides a connection pool that meets these
+    requirements, then that component might be your first choice.
+    </p>
+
+    <p>
+    The Jakarta Commons dbcp's BasicDataSource
+    [<code>org.apache.commons.dbcp.BasicDataSource</code>] also works well
+    with the DataSource manager, if a native component is not available.
+    </p>
+    
+    <p>
+    <strong>Note:</strong> The Generic DataSource which was included with previous 
+    versions of Struts has been removed as of release 1.2.0 in favor of 
+    plugging in the BasicDataSource, or another DataSource implementation.
+    </p>
+
+    <p>
+    This is how you would specify a DBCP BasicDataSource for your application:
+    </p>
+
+<pre><code><![CDATA[
+<data-sources>
+<!-- configuration for commons BasicDataSource -->
+<data-source type="org.apache.commons.dbcp.BasicDataSource">
+    <set-property
+      property="driverClassName"
+      value="org.postgresql.Driver" />
+    <set-property
+      property="url"
+      value="jdbc:postgresql://localhost/mydatabase" />
+    <set-property
+      property="username"
+      value="me" />
+    <set-property
+      property="password"
+      value="test" />
+    <set-property
+      property="maxActive"
+      value="10" />
+    <set-property
+      property="maxWait"
+      value="5000" />
+    <set-property
+      property="defaultAutoCommit"
+      value="false" />
+    <set-property
+      property="defaultReadOnly"
+      value="false" />
+    <set-property
+      property="validationQuery"
+      value="SELECT COUNT(*) FROM market" />
+</data-source>
+</data-sources>
+]]></code></pre>
+
+    <p>
+    Note that you can define as many datasource objects as your application
+    requires and refer to each using a logical name.
+    This can be useful in providing better security or scalability, or even
+    to test datasource implementations against each other.
+    </p>
+
+    <p>
+    After a DataSource is defined, here is an example of using the
+    manager to establish a connection from within an Action's
+    <code>execute</code> method.
+    </p>
+
+<pre><code>
+public ActionForward
+       execute(ActionMapping mapping,
+               ActionForm form,
+               HttpServletRequest request,
+               HttpServletResponse response) throws Exception
+{
+ javax.sql.DataSource dataSource;
+ java.sql.Connection myConnection;
+ try {
+  dataSource = getDataSource(request);
+  myConnection = dataSource.getConnection();
+  // do what you wish with myConnection
+ } catch (SQLException sqle) {
+    getServlet().log("Connection.process", sqle);
+ } finally {
+    //enclose this in a finally block to make
+    //sure the connection is closed
+    try {
+       myConnection.close();
+    } catch (SQLException e) {
+       getServlet().log("Connection.close", e);
+    }
+   }
+}
+</code></pre>
+
+    <p>
+    <em>Note: If you use the Commons BasicDataSource with Struts,
+    the query you provide for the pingQuery attribute (if you choose to
+    include it) must return at least one row.</em>
+    </p>
+
+    <p>
+    <strong>Example:</strong> <code>SELECT COUNT(*) FROM VALIDTABLE</code>
+    </p>
+
+    <p>
+    Just be sure you to replace "VALIDTABLE" with the name of a valid table
+    in your database.
+    </p>
+
+</section>
+
+<section name="Using Multiple Datasources" href="multi_dsrc">
+    <p>
+    If you need more than one data source in a module, you can include a key
+    attribute in the data-source element:
+    </p>
+<pre><code><![CDATA[
+<data-sources>
+   <data-source key="A" type="org.apache.commons.dbcp.BasicDataSource">
+      ... properties as before ...
+   </data-source>
+   <data-source key="B" type="org.apache.commons.dbcp.BasicDataSource">
+      ... properties as before ...
+   </data-source>
+   ...
+</data-sources>
+]]></code></pre>
+
+    <p>
+    Which can then be accessed by including the key ("A" in this case) as an
+    additional parameter to the Action.getDataSource() method.
+    </p>
+
+<pre><code>
+   ...
+   try {
+      dataSourceA = getDataSource(request, "A");
+      dataSourceB = getDataSource(request, "B");
+   ...
+</code></pre>
+
+    <p>
+    Each module can have as many data sources as it needs. The keys only
+    need to be unique within a module since the struts module system maintains
+    a name space for the items in each module to protect you from name
+    clashes.
+    </p>
+ </section>
+
+<section href="more" name="See Also">
+
+    <p>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24621.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24621.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24709.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24709.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24626.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24626.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24331.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24331.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24102.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24102.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23501.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23501.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23455.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23455.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23375.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23375.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23321.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23321.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23098.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23098.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22713.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22713.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg21974.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg21974.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg21026.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg21026.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19338.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19338.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18323.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18323.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14975.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14975.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14914.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14914.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14435.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg14435.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01562.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg01562.html</a>
+    </p>
+
+    <p>
+    Transformation/Data Transfer<br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24480.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24480.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23623.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg23623.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg10195.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg10195.html</a><br/>
+    <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg10205.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg10205.html</a>
+    </p>
+
+</section>
+
+
+<section href="DynaResultSet" name="Rendering a dynamic result set">
+
+    <p>
+        The result of most queries will map to the ActionForms you are already using,
+        and so you can render the ResultSet as a collection of ActionForms.
+        But sometimes there are columns in a ResultSet that are not properties of an ActionForm,
+        or even known in advance.
+    </p>
+
+    <p>
+        Happily, the Struts tags don't care what type of bean you use with them.
+        You could even output a ResultSet directly.
+        But a ResultSet retains a connection to the database, and passing "all that" directly to a JSP gets messy.
+        So what's a developer to do?
+    </p>
+
+    <p>
+        Since Struts 1.1, the simplest option is to use a
+        <a href="http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ResultSetDynaClass.html">ResultSetDynaClass</a>
+        to transfer the ResultSet into an ArrayList of DynaBeans.
+        The Struts custom tags can use DynaBean properties as easily as they use conventional JavaBean properties.
+        (See <strong>DynaActionForm classes</strong> in the Struts User Guide for details.)
+    </p>
+
+    <p>
+        Since this is in the BeanUtils jar, you already have it on board, and just need to implement the transfer routine
+        (see the ResultSetDynaClass link).
+    </p>
+
+</section>
+
+</body>
+</document>
+
diff --git a/build-legacy/core/xdocs/faqs/eclipse.xml b/build-legacy/core/xdocs/faqs/eclipse.xml
new file mode 100644
index 0000000..e876629
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/eclipse.xml
@@ -0,0 +1,232 @@
+<?xml version="1.0"?>
+
+<document url="./ssl.xml">
+
+<properties>
+
+
+<title>How to setup a basic Struts project using Eclipse IDE - Apache Struts</title>
+
+</properties>
+
+<body>
+
+<section href="eclipse" name="How to setup a basic Struts project using Eclipse IDE"/>
+<section name="Legal Disclamer">
+
+<p>
+* DISCLAIMER - This simple How-To shows you one of many ways to setup a working project using<br/>
+the Struts framework.  This is mainly geared toward struts users who are new to Eclipse, and<br/> 
+don't want to spend a lot of time figuring out the differences between their old IDE (if any)<br/>
+and this one.<br/>
+<br/>
+I will also apologize ahead of time for the formatting of this page.<br/>
+</p>
+<br/>
+In this How-To, I will demonstrate (using Eclipse 2.0.1) how to setup, compile, run,<br/> 
+and debug the struts-example web application that is bundled with the distribution.<br/>
+
+Next, I will modify the code to pull some data from a MySql database using the popular <br/>
+relational mapping tool OJB. (This is actually quite simple)
+
+</section>
+
+<section name="Let's get started">
+Before we begin, you will need to create a directory somewhere to store your project.<br/>
+I typically use C:\personal\development\Projects\(some project)<br/>
+Once that's done, extract the struts-example.war to that directory <br/>
+(using your favorite zip utility)<br/>
+<br/>
+Delete the META-INF folder because this will be created during the build/jar/war process.<br/>
+            
+Add a build.xml file to the project root.  I use something like this:
+
+  <pre>
+  
+  &lt;project name="Struts Example" default="main" basedir="."&gt;
+  
+    &lt;!--  This is a basic build script, only the minimums here --&gt;
+    
+    &lt;!-- Tell ant to use my environment variables --&gt;
+    &lt;property environment="env"/&gt;
+  
+    &lt;property file="./build.properties"/&gt;
+  
+      &lt;property name="build.compiler"     value="modern"/&gt;
+      &lt;property name="build.dir"          value="./WEB-INF/classes" /&gt;
+      &lt;property name="src.dir"            value="./WEB-INF/src"/&gt;
+    &lt;property name="servlet.jar"        value="/Apache_Home/jakarta-servletapi-4/lib/servlet.jar"/&gt;
+      &lt;property name="war.file"              value="struts-example"/&gt;
+      &lt;property name="war.file.name"      value="${war.file}.war"/&gt;
+      &lt;property name="tomcat.home"       value="${env.CATALINA_HOME}"/&gt;
+      &lt;property name="deploy.dir"         value="${tomcat.home}/webapps"/&gt;
+  
+    &lt;path id="project.class.path"&gt;
+        &lt;fileset dir="./WEB-INF/lib/"&gt;
+            &lt;include name="**/*.jar"/&gt;
+        &lt;/fileset&gt;
+        &lt;pathelement path="${src.dir}"/&gt;
+        &lt;pathelement path="${servlet.jar}"/&gt;
+    &lt;/path&gt;
+  
+      &lt;target name="clean"&gt;
+          &lt;delete dir="${build.dir}" includeEmptyDirs="true" /&gt;
+      &lt;/target&gt;
+  
+  
+      &lt;target name="prep"&gt;
+          &lt;mkdir dir="${build.dir}"/&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="compile"&gt;
+        &lt;javac   srcdir="${src.dir}"
+                    destdir="${build.dir}"
+                    debug="on"
+                deprecation="on"&gt;
+          &lt;include name="**/*.java"/&gt;
+          &lt;classpath refid="project.class.path"/&gt;
+        &lt;/javac&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="cleanWebApp"&gt;
+        &lt;delete file="${deploy.dir}/${war.file.name}" /&gt;
+          &lt;delete  dir="${deploy.dir}/${war.file}" includeEmptyDirs="true" /&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="war"&gt;
+          &lt;war warfile="${war.file.name}" webxml="./WEB-INF/web.xml"&gt;
+                 &lt;fileset dir="./" includes="**/*.*" excludes="*.war, **/*.nbattrs, web.xml, **/WEB-INF/**/*.*, **/project-files/**/*.*"/&gt;
+                 &lt;webinf  dir="./WEB-INF"    includes="**/*" excludes="web.xml, **/*.jar, **/*.class"/&gt;
+                 &lt;lib     dir="./WEB-INF/lib"/&gt;
+                 &lt;classes dir="${build.dir}" includes="**/*.properties" /&gt;
+          &lt;/war&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="deploy"&gt;
+          &lt;copy todir="${deploy.dir}"&gt;
+            &lt;fileset dir="./" includes="${war.file.name}"/&gt;
+          &lt;/copy&gt;
+      &lt;/target&gt;
+ 
+    &lt;target name="main" depends="clean, prep, cleanWebApp, compile, war"/&gt;
+  
+  &lt;/project&gt;
+  
+  </pre>
+
+    <ol>
+        <li>
+            Create a new project.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style01.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            New Java Project<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style02.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Browse for the folder you created for your project.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style03.jpg"></img><br/><br/><br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style04.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Eclipse will detect your source folders from any subdirectories under your project.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style05.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            In our case, this is where the src folder was placed.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style06.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Default standard libs are automatically added depending on the type of project.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style07.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Add the existing web app jars.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style08.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Now we need to add a few jars from the file system.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style09.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            We always need this one (servlet.jar)<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style10.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Ahhhh...everything looks ok for now.  You can always go back and modify these settings <br/>
+            later.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style11.jpg"></img><br/><br/><br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style12.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            When everything settles down, you should see something like this (of course, it might 
+            look different depending on your installation/customization):<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style13.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Compilation warnings and errors are detected immediately.  In this screenshot, I drill down<br/>
+            into the source folder, package, file, class, and double click on the method....which <br/>
+            brings up the source editor.  I hover the mouse over the offending warning to see <br/>
+            a description of what's wrong.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style14.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            I changed ApplicationConfig to ModuleConfig, then saved and now I see new errors.<br/>
+            You can right click and import ModuleConfig right from the error.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style15.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            A quick look at the import section.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style18.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Right click, Source, Organize Imports<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style20.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Ahhhh...better<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style21.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            From the Package Explorer, right click your build.xml and run Ant:<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style22.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Is this cool or what?<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style23.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Oh crap!<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style24.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Quick look at what jars are being used to process my build.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style26.jpg"></img><br/><br/><br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style25.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            I simply removed all the existing jars from the IDE's Ant configuration and<br/>
+            added all from my own installation.<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style27.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Can't forget that last one<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style28.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Everything went ok (for me)<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style30.jpg"></img><br/><br/><br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style29.jpg"></img><br/><br/><br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style31.jpg"></img><br/><br/><br/>
+        </li>
+        <li>
+            Time to test-drive<br/>
+            <img alt="" src="../images/how-to/eclipse/developing-eclipse-style32.jpg"></img><br/><br/><br/>
+        </li>
+    </ol>
+
+</section>
+
+
+
+</body></document>
diff --git a/build-legacy/core/xdocs/faqs/helping.xml b/build-legacy/core/xdocs/faqs/helping.xml
new file mode 100644
index 0000000..9cfd307
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/helping.xml
@@ -0,0 +1,424 @@
+<?xml version="1.0"?>
+<document url="./helping.xml">
+<properties>
+<title>How to Help FAQ - Apache Struts</title>
+</properties>
+
+<body>
+
+<section href="faq" name="How to Help FAQ"/>
+
+<section href="contents" name="Index">
+
+<p>
+
+"You can't always get what you want / 
+but if you try real hard / 
+you might just find /
+that you get what you need". 
+<br/>
+[Rolling Stones]
+</p>
+
+<ul>
+    <li><a href="#corp">
+    What can my company do to help support Struts?
+    </a></li>
+    <li><a href="#bugs">
+    How can I report bugs or make feature requests?
+    </a></li>
+    <li><a href="#contribute">
+    How can I contribute to Struts source code?
+    </a></li>
+    <li><a href="#documentation">
+    How can I contribute to the documentation?
+    </a></li>
+    <li><a href="#release">
+    So when is the next release coming out?
+    </a></li>
+    <li><a href="#release_help">
+    How can I help the next release along?
+    </a></li>
+</ul>
+
+</section>
+
+<section href="corp" name="What can my company do to help support Struts?">
+
+<p>
+Struts is an all volunteer product. 
+Our customers are the volunteers who donate their time and energy to 
+supporting the product. 
+If you want to support Struts, and become one of our customers, 
+then you need to 
+<a href="http://jakarta.apache.org/site/getinvolved.html">get involved</a>
+and become a volunteer.
+</p>
+
+<p>
+Our challenge to any team using Struts is to donate the time of one team member 
+one afternoon a week (or more if you can spare the resources). 
+Have your team member browse 
+<a href="http://jakarta.apache.org/site/bugs.html">Bugzilla</a> for any issues 
+without a patch or unit test, 
+and add the patch or test.
+If the patch is written on company time, 
+and you want to give your company an author's credit, that's fine with us.
+</p>
+
+<p>
+If Struts doesn't do what <em>you</em> want, it's up to <strong>you</strong> to step up 
+and propose the patch.
+If Struts doesn't ship as often as you would like, it's up to you to step up 
+with the tests and fixes that get a release out the door.
+</p>
+
+<p>
+If Struts does do what you want, help others become involved by turning your 
+war stories into FAQs and how-tos that we can make part of the 
+<a href="#documentation">documentation</a>. 
+The mailing list is very active and trundling through the archives is no 
+picnic. 
+We can always use people who can reduce the best threads to coherent articles 
+that we can put in the User Guide.
+</p>
+
+<p>
+Some Apache products like you to submit your patch to the mailing list. 
+We would prefer that you create a 
+<a href="http://jakarta.apache.org/site/bugs.html">Bugzilla</a>
+Bugzilla report and then attach the patch to the report. 
+To do this, you must first create the report, 
+and then modify the report to add your patch. 
+We realize this is a bit clumsy, but it keeps us from losing things, 
+and helps to ensure that your patch will be attended.
+</p>
+
+<p>
+We don't sell Struts for money, but anyone who wants to be our customer 
+can pay us back by donating the time and energy that money represents.
+</p>
+
+</section>
+
+<section href="bugs" name="How can I report bugs or make feature requests?">
+
+<p>
+You can research and report outstanding fixes and feature requests using
+<a href="http://jakarta.apache.org/site/bugs.html">Jakarta Bugzilla</a>. 
+If you are unsure if this is an actual problem, feel free to bring it up the 
+list first. 
+But to be sure that an issue is resolved, read 
+<a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">
+How to Report Bugs Effectively</a> and report it to
+<a href="http://jakarta.apache.org/site/bugs.html"><strong>Bugzilla</strong></a>.
+</p>
+
+<p>
+Feature requests are also maintained in the Bugzilla database. 
+</p>
+
+<p>
+<a href="http://jakarta.apache.org/site/source.html">Patches</a> are always
+welcome. 
+If you can't write a patch to fix your bug, a <a href="kickstart.html#tests">unit test</a>
+that demonstrates the problem is also welcome.
+(And, of course, unit tests that prove your patch works are equally welcome.)
+</p>
+
+<p>
+If your bug or feature is already in Bugzilla, <strong>you can vote</strong>
+for the issue and call more attention to it. 
+Each user can cast up to six votes at a time.
+</p>
+
+<p>
+If there is a patch attached to the issue, you can also try applying
+to your local copy of Struts, and report whether it worked for you.
+Feedback from developers regarding a proposed patch is really quite
+helpful. 
+Don't hesitate to "me too" if you've tried the patch yourself.
+</p>
+
+</section>
+
+<section href="contribute" 
+    name="How can I contribute to the Struts source code?">
+
+<p>
+Struts is distributed by <a href="http://apache.org/">
+The Apache Software Foundation</a>.
+These are the same people who distribute the Apache Web server. 
+Like all ASF projects, Struts is managed as a &quot;meritocracy&quot;, 
+where everyone's contribution is welcome. 
+Users can help other users the 
+<a href="http://jakarta.apache.org/site/mail.html">mailing lists</a>,
+<a href="http://jakarta.apache.org/site/bugs.html">report bugs</a>, and
+<a href="http://jakarta.apache.org/site/bugs.html">request new features</a>. 
+Developers can
+contribute patches, new code, and documentation. 
+The most active Developers may become
+<a href="http://jakarta.apache.org/site/roles.html">Committers</a>, 
+who make the actual decisions about Strut's codebase.
+</p>
+
+<p>
+If you are new to open source development, see the
+<a href="http://jakarta.apache.org/site/getinvolved.html">
+How to get involved</a> page the main Jakarta site.
+</p>
+
+<p>
+A very good place to start is by <strong>reviewing the list of open issues</strong> and 
+pending feature requests (<a href="#bugs">Bugzilla</a>). 
+If you see an issue that needs a patch you can write, 
+feel free to annex your patch. 
+If you seen an issue that needs a unit test to prove its fixed, 
+feel free to annex your test case. 
+If someone has posted a patch to an issue you'd like to see resolved, 
+apply the patch to your local development copy of Struts. 
+Then let us know if it works for you, and if it does, 
+cast your vote for the issue and its patch.
+</p>
+
+<p>
+If none of the pending issues scratch your itch, 
+another good place to start is by <strong>contributing unit tests</strong> 
+for existing features (even those that still work).
+</p>
+
+<p>
+Our current approach to <a href="kickstart.html#tests">unit testing</a>
+works fairly well for exercising most method-level stuff, but does
+not really address situations of dynamic behavior -- most particularly the
+execution of custom tags for Struts.  
+You can try to fake what a JSP container does, but a much more reliable 
+testing regime would actually execute the tag in a real container.  
+For that purpose, we use the 
+<a href="http://jakarta.apache.org/cactus">Cactus</a> testing framework, 
+which re-executes the JUnit-based tests as well to make sure that nothing 
+bad happens when you switch environments.  
+Right now, there are very few dynamic tests; ideally, we will have tests 
+for every tag, that cover every reasonable combination of tag attribute 
+values (yes, that's a tall order -- the totally lines of test source code 
+will undoubtedly exceed the totally lines of code in the framework itself 
+if we achieve this).
+</p>
+
+</section>
+
+<section href="documentation" 
+    name="How can I contribute to the documentation?">
+
+<p>
+The only difference is that the documentation is kept in XML rather than Java
+source code. 
+Otherwise, all the same precepts and procedures pertain.
+</p>
+
+<p>
+The trick to getting started is to download the nightly build and try building 
+the documentation WAR. 
+Then try adding your own XML page under doc/ to see if the build succeeds. 
+If it doesn't, it will report where the bad element is, much like it reports 
+where a bad programming expression is. 
+If it does, then your page should be available under target/documentation/.
+</p>
+
+<p>
+The website portion of the package is the root directory of doc/. 
+The User Guide portion is under the userGuide/ folder. 
+If the material you'd to add doesn't fit right in with what's there, 
+the best thing may to start a new section after the existing material. 
+The navigation column can be found in the project.xml document.
+</p>
+
+<p>
+To display markup, substitute &amp;lt; for &lt;. 
+The unmatched trailing > will be ignored. 
+Since it is XML, all elements also need to closed. 
+So elements like &lt;br> and &lt;hr> need to set out as &lt;br/> and &lt;hr/>.
+</p>
+
+<p>
+Also watch for the length of code samples - 
+these do not wrap. 
+If a line is too long, it will force the right margin out past the edge of the 
+screen or printed page.
+</p>
+
+<p>
+The stylesheets we use are adequate, but could certainly be improved by an XML
+guru, if you happen to one of those.
+</p>
+
+</section>
+
+<section href="release" name="So when is the next release coming out?">
+
+<p>
+Here is the truth regarding releases:
+</p>
+
+<p>
+Jakarta products are released on the basis of merit, and ~not~ according
+to a strict timetable. 
+The volunteers devote whatever time they can to work on the product. 
+But all volunteers have real jobs and real lives, that do take precedence. 
+Since Struts does not have paid personnel working on the project, 
+we simply cannot make date-oriented commitments.
+</p>
+
+<p>
+All Jakarta products must circulate a public beta before release. 
+If a beta is not in circulation, 
+then it's a good bet that a release is not forthcoming any time soon. 
+Products sometimes go through several betas before final release. 
+So if this is beta 1, then it still may not be released any time soon.
+</p>
+
+<p>
+The bottom line is that Jakarta takes releases very seriously. 
+We do not compromise the quality of our software by watching the calendar 
+(and then ship something ready or not). 
+A release is ready when it is ready.
+</p>
+
+<p>
+That may sound flip, but it ~is~ the truth. 
+The delivery of production-quality, leading-edge software is not something 
+anyone can prognosticate. 
+If anyone tries, they are lying to you. 
+That, we won't do ;-)
+</p>
+
+<p>
+What we ~will~ do is release all of our development software as soon as it is 
+developed. 
+This way you can judge for yourself how quickly the development is proceeding, 
+and whether what is being developed will meet your needs. 
+If you need a feature right now, you can use the nightly build, or roll your 
+own patch. 
+There are no private Subversion repositories or private development lists. 
+What you see is what we got. 
+If you are following the DEV list, then you know everything the developers 
+know. 
+Really, you do.
+</p>
+
+<p>
+<em>So, what do you tell your team?</em> 
+If you can ship your application based on the nightly build of your choice, 
+then consider that an option. 
+You can still ship yours, even if we don't ship ours, 
+and you will have access to all the latest patches or enhancements. 
+(Just like we were working down the hall.) 
+If you can only ship your application based on a release build of Struts, 
+then you should base your development on the release build of Struts,
+and keep an eye on what is coming down the pipeline. 
+This way you are at least forewarned and forearmed.
+</p>
+
+</section>
+
+<section href="release_help" 
+    name="What can I do to help the next release along?">
+
+<ul>
+
+<li>
+  Most importantly, <strong>download the latest beta</strong> or release-candidate and 
+  test it against your own applications. 
+  Report any and all issues or suspected issues to 
+  <a href="http://jakarta.apache.org/site/bugs.html">Bugzilla</a>. 
+  The sooner we resolve any problems, the fewer betas or release candidates 
+  we will have to distribute before we are done. 
+  (How do we know when we're done? -- When we run out of issues =:o) 
+  The sooner we find them, the sooner we are done.)
+</li>
+
+<li>
+  <strong>Contribute <a href="kickstart.html#tests">unit tests</a></strong>. 
+  The closer we get to a release, the more we worry about breaking something. 
+  The more tests we have, the more confident we can be when applying patches. 
+  Tests that prove that a pending issue is actually a bug are the most 
+  welcome ones. 
+  But we are eager for any and all tests for any and all features, 
+  even those that still work =:0).
+</li>
+
+<li>
+  <strong>Review the list of issues</strong> at <a href="#bugs">Bugzilla</a>. 
+  If there are any to which you can respond, please do. 
+  If there any patches posted, feel free to test them your system, 
+  report the results, and cast your vote if they work.
+</li>
+
+<li>
+  <strong>Confirm an issue's category and status</strong>. 
+  Newbies often post feature requests or help-desk questions as "bugs". 
+  This bloats the list of fixes we (apparently) need to apply before the next 
+  beta, making it hard to see the forest for the trees. 
+  If an issue doesn't seem to be categorized correctly, exercise your best 
+  judgment and change it.
+  If one ticket seems like a duplicate of another, go ahead and enter the 
+  change. 
+  Every modification to the ticket is echoed to the DEV list and 
+  automatically subjected to peer review. 
+  Err on the side of doing.
+</li>
+
+<li>
+  Use Bugzilla to <strong>vote for issues</strong> you feel should be handled
+  first. 
+  If an issue on your ballot doesn't include a patch, feel free to try coding 
+  one yourself. 
+  (At Jakarta, patches are the only votes that truly count.) 
+  Well over <a href="../volunteers.html">thirty developers</a> have contributed 
+  code or documentation to the product. 
+  You can too =:0)
+</li>
+
+<li>
+  <strong>Answer questions on the user list.</strong> 
+  The Committers only have a limited amount of time to volunteer. 
+  If Developers are supporting each other on the lists, 
+  the Committers have more time to spend on the next release.
+</li>
+
+</ul>
+
+</section>
+
+<section href="decisions" 
+    name="Who makes the final decisions regarding Struts">
+
+<p>
+The management of the Jakarta site, and the Struts product, is based on 
+principles and practices used by creators of the Apache HTTPD server. 
+Struts follows the 
+<a href="http://jakarta.apache.org/site/guidelines.html">Project Guidelines</a>
+on the main Jakarta site.
+</p>
+
+<p>If you are new to this style of development, 
+the Apache HTTPD Dev list is available in a 
+<a href="mailto:dev-digest-subscribe@httpd.apache.org">digest form</a>. 
+Even if you are not working on the HTTPD server yourself, 
+it is interesting to watch how the HTTPD team works on the server.
+</p>
+
+<p>
+The Struts project has its own <a href="../using.html#Lists">Dev list</a>, 
+where all of the decisions regarding Struts are made. 
+Most development takes place via
+<a href="http://jakarta.apache.org/site/proposal.html#decisions/voting/items">
+Lazy Consensus</a>.
+Committers post most changes to the product unilaterally, using their own best 
+judgment, and only discuss or vote upon controversial matters. 
+Another Committer can veto any change in an unreleased product with cause.
+</p>
+
+</section>
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/faqs/index.xml b/build-legacy/core/xdocs/faqs/index.xml
new file mode 100644
index 0000000..b000762
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/index.xml
@@ -0,0 +1,117 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<document url="./index.xml" authors="false">
+
+<properties>
+    <title>FAQs and Howtos - Apache Struts</title>
+</properties>
+
+<body>
+
+<section name="Struts FAQs">
+
+ <ul>
+
+    <li>
+    <a href="kickstart.html">Kickstart FAQ</a> (read me first)
+    </li>
+
+    <li>
+    <a href="newbie.html">Newbie FAQ</a>
+    </li>
+
+    <li>
+    <a href="helping.html">How to Help FAQ</a>
+    </li>
+
+     <li>
+     <a href="works.html">How does Struts work?</a>
+     </li>
+
+ </ul>
+
+</section>
+
+<section name="Howto Guides">
+
+ <ul>
+
+    <li>
+    <a href="actionForm.html">Building an Action Form</a>
+    </li>
+    
+    <li>
+    <a href="apps.html">Building Applications</a>
+    </li>
+    
+    <li>
+    <a href="database.html">Accessing a Database</a>
+    </li>
+
+    <li>
+    <a href="indexedprops.html">Indexed Properties, Mapped Properties, and Indexed Tags</a>
+    </li>
+
+    <li>
+    <a href="ssl.html">Using the SSL protocol</a>
+    </li>
+    
+    <li>
+    <a href="struts-el.html">Struts EL Extension</a>
+    </li>
+
+ </ul>
+
+</section>
+
+<section name="IDE Guides">
+
+ <ul>
+
+    <li>
+    <a href="eclipse.html">Installing the Eclipse IDE</a>
+    </li>
+
+    <li>
+    <a href="netbeans.html">Installing the Netbeans IDE</a>
+    </li>
+    
+ </ul>
+
+</section>
+
+<section name="External FAQs and Howtos">
+
+<ul>
+   <li>
+   <a href="http://wiki.apache.org/struts">Apache Struts Wiki</a>
+   </li>
+</ul>
+
+ <ul>
+    <li>
+    <a href="http://www.jguru.com/faq/home.jsp?topic=Struts">jGuru FAQ</a>
+    </li>
+ </ul>
+
+<ul>
+   <li>
+   <a href="http://www.husted.com/struts/tips">Struts Tips</a> by Ted Husted
+   </li>
+</ul>
+
+ <ul>
+    <li>
+    <a href="http://strutstestcase.sourceforge.net">Unit Testing with Struts TestCase</a> by Deryl Seale
+    </li>
+ </ul>
+
+<ul>
+   <li>
+   <a href="http://tinyurl.com/6jnv">Struts Validator: Validating Two Fields Match</a> by Matt Raible
+   </li>
+</ul>
+
+</section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/faqs/indexedprops.xml b/build-legacy/core/xdocs/faqs/indexedprops.xml
new file mode 100644
index 0000000..5c5f0fb
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/indexedprops.xml
@@ -0,0 +1,380 @@
+<?xml version="1.0"?>
+
+<document url="./indexedprops.xml">
+ <properties>
+  <title>Indexed Properties, Mapped Properties, and Indexed Tags</title>
+ </properties>
+ <body>
+  <section name="Indexed Properties, Mapped Properties, and Indexed Tags"/>
+   <section href="introduction" name="Introduction">
+    <p>
+     The JSP specification discusses using "indexed properties" in reference to
+     the &lt;jsp:setProperty&gt; tag.  However, none of the support provided in
+     the base JSP specification actually deals with the "indexing" part.  In
+     truth, it allows for setting "array properties", but it doesn't do much
+     for setting or even getting the actual values in each entry of the array,
+     except with explicit JSP expressions (&lt;%=  %&gt;).
+    </p>
+    <p>
+     The Struts framework provides much more powerful features related to
+     indexed properties, but in truth most of the heavy lifting is not even in
+     the Struts framework, but in the Jakarta Commons Beanutils package.  This
+     package is used by Struts to provide this functionality.  You can see the
+     javadoc documentation for the Beanutils package at <a
+     href="http://jakarta.apache.org/commons/beanutils/api/index.html">http://jakarta.apache.org/commons/beanutils/api/index.html</a>.
+     The information particularly related to indexed properties is in the
+     package description for the org.apache.commons.beanutils package.  This
+     article mirrors that information, but focuses on how this functionality is
+     mapped to JSP tags using the Struts tag library.
+    </p>
+    <p>
+     The support for indexed properties also includes "mapped properties",
+     "nested properties" and "indexed tags", which are all related but slightly
+     different.  The latter is exclusive to Struts, but the first two are also
+     provided by the Beanutils package.  This article will cover all three of
+     these topics.
+    </p>
+   </section>
+   <section href="indexedprops" name="Indexed Properties">
+    <p>
+     The simplest demonstration of using indexed properties in Struts can be
+     shown with the following simple bean and JSP page:
+    </p>
+     <pre>
+package org.apache.struts.webapp.exercise;
+import org.apache.struts.action.ActionForm;
+public class StringBean extends ActionForm {
+    private String strAry[] = { "String 0", "String 1", "String 2", "String 3", "String 4" };
+
+    public String getStringIndexed(int index) { 
+        return strAry[index]; 
+    }
+    
+    public void setStringIndexed(int index, String value) { 
+        strAry[index] = value; 
+    }
+}</pre>
+    <p>
+     First note the two methods in the StringBean class, "getStringIndexed()"
+     and "setStringIndexed()".  Note that the "get" method takes an "int" and
+     the "set" method takes an "int" and "String".  The Beanutils package and
+     Struts recognizes this arrangement of signatures as an "indexed property",
+     in this case with the property name "stringIndexed".
+    </p>
+    <pre>
+&lt;!-- indexedtest.jsp --&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %&gt;
+&lt;jsp:useBean id="bean" class="org.apache.struts.webapp.exercise.StringBean"/&gt;
+&lt;bean:write name="bean" property="stringIndexed[1]"/&gt;</pre>
+    <p>
+     Note the property value of "stringIndexed[1]".  This is intended to
+     reference the indexed property "stringIndexed", and the 1st (zero-based)
+     entry of whatever array or collection which the indexed property
+     represents.
+    </p>
+    <p>
+     As you might be able to guess, when this page is executed, it will print
+     just the string "String 1", which is the corresponding array entry at that
+     index value.
+    </p>
+    <p>
+     This is a simple demonstration of what indexed properties can provide.
+    </p>
+   </section>
+   <section href="listbackedprops" name="List-Backed Indexed Properties">
+    <p>
+     A variation on indexed properties are properties whose type is
+     <code>java.util.List</code> or a subclass.
+    </p>
+    <p>
+     For instance, the first example using "StringBean.java" and
+     "indexedtest.jsp" could use a modified "StringBean.java" class, like this:
+    </p>
+    <pre>
+package org.apache.struts.webapp.exercise;
+import org.apache.struts.action.ActionForm;
+public class StringBean2 extends ActionForm {
+    private String strAry[] = { "String 0", "String 1", "String 2", "String 3", "String 4" };
+
+    public java.util.List getStringIndexed(int index) { 
+        return java.util.Arrays.asList(strAry);
+    }
+}</pre>
+    <p>
+     Note the different implementation of the "getStringIndexed()" method,
+     returning a List instead of a String.  If this bean class is substituted
+     with the original "indexedtest.jsp", the result will be identical.
+    </p>
+   </section>
+   <section href="mappedprops" name="Mapped Properties">
+    <p>
+     The idea of "mapped properties" as opposed to "indexed properties" is that
+     the property represents a "map" type, as opposed to an array or collection
+     type.  The signature of the "get" and "set" methods for a mapped property
+     are different from the same methods for an indexed property.  In
+     particular, instead of an "int" for the index, there is a "String" for the
+     key.
+    </p>
+    <p>
+     The previous example for indexed properties can be changed to the
+     following to demonstrate mapped properties:
+    </p>
+    <pre>
+package org.apache.struts.webapp.exercise;
+import java.util.HashMap;
+import org.apache.struts.action.ActionForm;
+public class StringBean3 extends ActionForm {
+    private String strAry[] = { "String 0", "String 1", "String 2", "String 3", "String 4" };
+    
+    private HashMap map = new HashMap();
+
+    public StringBean() {
+        map.put("zero", strAry[0]);
+        map.put("one", strAry[1]);
+        map.put("two", strAry[2]);
+        map.put("three", strAry[3]);
+        map.put("four", strAry[4]);
+    }
+
+    public Object getStringMapped(String key) { 
+        return map.get(key);
+    }
+    
+    public void setStringMapped(String key, Object value) { 
+        map.put(key, value); 
+    }
+}</pre>
+    <p>
+     Note the "get" and "set" methods to represent the mapped property.
+    </p>
+    <pre>
+&lt;!-- indexedtest3.jsp --&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %&gt;
+&lt;jsp:useBean id="bean" class="org.apache.struts.webapp.exercise.StringBean"/&gt;
+&lt;bean:write name="bean" property="stringMapped(two)"/&gt;</pre>
+    <p>
+     Note the property value of "stringMapped(two)".  This will reference the
+     mapped property "stringMapped", using the key value of "two".
+    </p>
+    <p>
+     When this page is executed, it will print just the string "String 2",
+     which is the string stored in the HashMap with the key "two".
+    </p>
+   </section>
+   <section href="nestedprops" name="Nested Properties">
+    <p>
+     Nested properties allows you to combine normal properties, indexed
+     properties, and mapped properties in a hierarchical fashion. A property
+     value of a bean does not have to be a primitive like "int" or "String.
+     The property value can be a bean with its own properties.  The following
+     example demonstrates this.
+    </p>
+    <pre>
+package org.apache.struts.webapp.exercise;
+import org.apache.struts.util.LabelValueBean;
+import org.apache.struts.action.ActionForm;
+public class StringBean4 extends ActionForm {
+    private LabelValueBean[] lvbeans;
+    
+    public StringBean() {
+        lvbeans   = new LabelValueBean[5];
+        lvbeans[0]   = new LabelValueBean("Zero", 0+"");
+        lvbeans[1]   = new LabelValueBean("One", 1+"");
+        lvbeans[2]   = new LabelValueBean("Two", 2+"");
+        lvbeans[3]   = new LabelValueBean("Three", 3+"");
+        lvbeans[4]   = new LabelValueBean("Four", 4+"");
+    }
+
+    public  LabelValueBean getLabelValue(int index) { 
+        return lvbeans[index];
+    }
+}</pre>
+    <p>
+     First note the use of the class "LabelValueBean".  This is a simple class
+     provided in the Struts library which represents a pair of two Strings, a
+     "label" and a "value".  It itself is a bean, providing these two
+     properties with standard getters and setter methods.
+    </p>
+    <p>
+     Then, see the "getLabelValue()" method, representing the indexed property
+     "labelValue".  This class doesn't show a "setter" method. If you only ever
+     provide read-only access a property, then it is not necessary to provide a
+     setter method.
+    </p>
+    <pre>
+&lt;!-- indexedtest4.jsp --&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %&gt;
+&lt;jsp:useBean id="bean" class="org.apache.struts.webapp.exercise.StringBean"/&gt;
+&lt;bean:write name="bean" property="labelValue[1].label"/&gt;</pre>
+    <p>
+     Note here the "nested" property reference. It is first using the indexed
+     property "labelValue" and then the "normal" property of the LabelValueBean
+     to get the final result.  When this page is executed, it will print the
+     string "One", representing the "label" property of the 1st entry of the
+     array represented by the "labelValue" indexed property.
+    </p>
+   </section>
+   <section href="dynamicindexes" name="Dynamic Indexes for Indexed Properties">
+    <p>
+     When people started using indexed properties in Struts tags, I'm
+     reasonably certain they started out with a high level of enthusiasm, but
+     were somewhat frustrated when they discovered reality.  The reality is
+     that the "index" for indexed properties often needs to be a dynamic value,
+     usually from the "indexId" counter in the "&lt;logic:iterate&gt;" tag.
+    </p>
+    <p>
+     For instance, the following example JSP page using the same "StringBean"
+     bean class uses a dynamic value for the index:
+    </p>
+    <pre>
+&lt;!-- indexedtest5.jsp --&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %&gt;
+&lt;html&gt;
+ &lt;body&gt;
+  &lt;html:form action="indexedtest5.do"&gt;
+   &lt;logic:iterate name="stringbean" property="stringArray" id="foo"
+                  indexId="ctr"&gt;
+    &lt;html:text name="stringbean"
+               property='&lt;%= "labelValue[" + ctr + "].label" %&gt;' /&gt;
+   &lt;/logic:iterate&gt;
+   &lt;html:submit property="submitValue"&gt;Submit Changes&lt;/html:submit&gt;
+  &lt;/html:form&gt;
+ &lt;/body&gt;
+&lt;/html&gt;</pre>
+    <p>
+     The JSP expression syntax for the <code>property</code> attribute is somewhat 
+     messy and easy to get wrong so it's something we want to avoid. One
+     way to make this a little cleaner is to use "indexed tags", but there's a
+     wrinkle to this approach.  We'll first cover the details of indexed tags,
+     then we'll talk about the wrinkle, and then finally an alternative to
+     indexed tags.
+    </p>
+   </section>
+   <section href="indexedtags" name="Indexed Tags">
+    <p>
+     The "indexed tags" feature is provided by several tags that have an
+     optional boolean "indexed" attribute.  This is only legal when inside a
+     "&lt;logic:iterate&gt;" tag.  When the "indexed" attribute is true, then
+     the tag will incorporate the loop index into the resulting HTML component.
+    </p>
+    <p>
+     The several tags that support the "indexed" attribute can be broken into
+     three groups, split by what they do to incorporate the loop index into the
+     resulting HTML component.
+    </p>
+    <table>
+     <thead>
+     <tr>
+      <th>Group 1</th><th>Group 2</th><th>Group 3</th>
+     </tr>
+     </thead>
+     <tr><td>checkbox</td><td>button</td><td>link</td></tr>
+     <tr><td>file</td><td>image</td><td>&#160;</td></tr>
+     <tr><td>hidden</td><td>submit</td><td>&#160;</td></tr>
+     <tr><td>password</td><td>&#160;</td><td>&#160;</td></tr>
+     <tr><td>radio</td><td>&#160;</td><td>&#160;</td></tr>
+     <tr><td>select</td><td>&#160;</td><td>&#160;</td></tr>
+     <tr><td>text</td><td>&#160;</td><td>&#160;</td></tr>
+     <tr><td>textarea</td><td>&#160;</td><td>&#160;</td></tr>
+    </table>
+    <p>
+     In Group 1, all of these tags will generate an HTML "name" attribute of
+     "name[nn].property".  The value of each tag will also be initialized by
+     the getter method corresponding to that property specification.
+    </p>
+    <p>
+     In Group 2, these tags will generate an HTML "name" attribute of
+     "property[nn]".  These three tags don't have "name" attributes, so since
+     it wouldn't make sense to use "[nn].property" (no name value), the array
+     indexes are attached to the property instead.
+    </p>
+    <p>
+     The "link" tag in Group 3 isn't anything like any of the others.  The base
+     description of the "link" tag doesn't even mention how this works, but the
+     description of the "indexed" tag describes how it works somewhat (although
+     it doesn't specifically say that it uses the name "index" if "indexId"
+     isn't set).  In short, the "indexed" behavior of this tag is to add a URL
+     query parameter, where the parameter name is "index" or the value of the
+     "indexId" attribute, and the parameter value is the current index value.
+     Outside of this, the "indexed" behavior of the "link" tag needs no more
+     explanation, in contrast to the tags in the first two groups.
+    </p>
+   </section>
+   <section href="wrinkle" name="The Wrinkle with Indexed Tags">
+    <p>
+     The problem with using the "indexed" attribute to automatically attach the
+     loop index is that it gives you less control over how the loop index is
+     used.  For instance, in our earlier examples using the "&lt;html:text&gt;"
+     tag, we attached the loop index to the end of the "property" attribute
+     value, which was "labelValue" in our example.  This results in a "name"
+     attribute value in the HTML component of "labelValue[nn]".  This maps to a
+     "labelValue" indexed property on the "stringbean" bean instance.
+    </p>
+    <p>
+     However, if we instead add the "indexed" attribute, and remove the manual
+     attachment of the loop index, then the resulting "name" attribute in the
+     HTML component ends up as "stringbean[nn].labelValue".  This will not work
+     as is.  It can be changed to work, however.  From the previous example
+     (indexedtest5.jsp), the "&lt;html:text&gt;" component would change the
+     "name" attribute from "stringbean" to "labelValue", and the "property"
+     attribute to "label".  With the "indexed" attribute, that ends up with a
+     "name" attribute value of "labelValue[nn].label".
+    </p>
+    <p>
+     So, it's very likely you could use indexed tags to support your needs for
+     indexed properties, but you have to understand the resulting structure of
+     your "name" attribute in order to understand what other attribute values
+     you need.
+    </p>
+   </section>
+   <section href="strutsel" name="Using Struts-EL To Avoid Some Of The Pain">
+    <p>
+     The "indexed tags" feature was created partially because of the awkward
+     process for encoding the loop index into the property attribute, using a
+     JSP expression.  The creation of the <a href="http://java.sun.com/products/jsp/jstl/">JSTL</a> 
+     eventually resulted in a solution that makes that process less painful.
+    </p>
+    <p>
+     The JSTL uses a string-based expression language to evaluate attribute
+     values, instead of using a run-time JSP expression.  The engine that
+     performs these evaluations is often called just "EL" (expression language)
+     for short.  After the JSTL was created, a derivative of the Struts tag
+     library called Struts-EL was created.  In short, this does everything that
+     the Struts tag library does, but it uses the JSTL EL engine to evaluate
+     attribute values.
+    </p>
+    <p>
+     If you use Struts-EL, you can get back some of the flexibility of encoding
+     your loop indices manually, but the resulting expressions will be a little
+     more readable, and thus maybe a little easier to maintain.
+    </p>
+    <p>
+     For instance, following this is a version of "indexedtest5.jsp" using
+     Struts-EL:
+    </p>
+    <pre>
+&lt;!-- indexedtest6.jsp --&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-html-el.tld" prefix="html-el" %&gt;
+&lt;%@ taglib uri="/WEB-INF/struts-logic-el.tld" prefix="logic-el" %&gt;
+&lt;html&gt;
+ &lt;body&gt;
+  &lt;html-el:form action="indexedtest6.do"&gt;
+   &lt;logic-el:iterate name="stringbean" property="stringArray" id="foo"
+                     indexId="ctr"&gt;
+    &lt;html-el:text name="stringbean"
+                  property="labelValue[${ctr}].label" /&gt;
+   &lt;/logic-el:iterate&gt;
+   &lt;html-el:submit property="submitValue"&gt;Submit Changes&lt;/html:submit&gt;
+  &lt;/html-el:form&gt;
+ &lt;/body&gt;
+&lt;/html&gt;</pre>
+    <p>
+     The Struts-EL library is part of the Struts distribution, in the "contrib"
+     directory.  The one drawback to using Struts-EL is that it requires a web
+     container supporting the Servlet 2.3 specification.
+    </p>
+   </section>
+ </body>
+</document>
+
diff --git a/build-legacy/core/xdocs/faqs/kickstart.xml b/build-legacy/core/xdocs/faqs/kickstart.xml
new file mode 100644
index 0000000..08f0639
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/kickstart.xml
@@ -0,0 +1,356 @@
+<?xml version="1.0"?>
+<document url="./kickstart.xml">
+<properties>
+<title>Kickstart FAQ - Apache Struts</title>
+</properties>
+<body>
+<section href="faq" name="Kickstart FAQ"/>
+
+<section href="contents" name="Index">
+
+<p>
+Here are answers to the usual getting-started questions. <strong>For an in-depth, searchable FAQ, visit our friends at <a href="http://www.jguru.com/faq/home.jsp?topic=Struts">JGuru</a>.</strong>
+</p>
+
+  <ul>
+    <li><a href="#why">Why do we need Struts?</a></li>
+    <li><a href="#how">How does Struts work?</a></li>
+    <li><a href="#compat">Is Struts compatible with other Java technologies?</a></li>
+    <li><a href="#who">Who wrote Struts?</a></li>
+    <li><a href="#struts">Why is it called Struts?</a></li>
+    <li><a href="#license">How is Struts licensed?</a></li>
+    <li><a href="#usage">Can Struts be used in a commercial application?</a></li>
+    <li><a href="#credits">Do I have to credit Struts on my own website?</a></li>
+  </ul><ul>
+    <li><a href="#where">Where can I get a copy of Struts?</a></li>
+    <li><a href="#install">How do I install Struts?</a></li>
+    <li><a href="#jar">When do I need the struts.jar on my classpath?</a></li>
+    <li><a href="#tests">Does Struts provide its own unit tests?</a></li>
+  </ul><ul>
+    <li><a href="#requests">If the framework doesn't do what I want, can I request that a feature be added?</a></li>
+    <li><a href="#help">Where can I get help with Struts?</a></li>
+    <li><a href="#support">Is commercial support available for Struts?</a></li>
+    <li><a href="#providers">Are there ISPs that will host my Struts application?</a></li>
+    <li><a href="#powered">What Web sites are already Powered by Struts?</a></li>
+  </ul><ul>
+    <li><a href="#turbine">What's the difference between Struts and Turbine?  What's the difference between Struts and Expresso?</a></li>
+    <li><a href="#taglibs">Why aren't the Struts tags maintained as part of the Jakarta Taglibs project?</a></li>
+    <li><a href="#xhtml">Are the Struts tags XHTML compliant?</a></li>
+    <li><a href="#jsf">What about JSTL and JavaServer Faces?</a></li>
+    <li><a href="#ide">Is there a particularly good IDE to use with Struts?</a></li>
+ </ul><ul>
+    <li><a href="#digest">Is there a digest for the mailing list?</a></li>
+    <li><a href="#newsgroup">Is there a Struts Newsgroup?</a></li>
+    <li><a href="#mailbounce">Why didn't my posting show up on the user list?"</a></li>
+    <li><a href="#unsubscribe">How do I unsubscribe from the mailing list?</a></li>
+  </ul>    
+</section>
+
+<section href="why" name="Why do we need Struts?">
+<p>Java technologies give developers a serious boost when creating and maintaining applications to meet the demands of today's public Web sites and enterprise intranets. Struts combines Java Servlets, Java ServerPages, custom tags, and message resources into a unified framework. The end result is a cooperative, synergistic platform, suitable for development teams, independent developers, and everyone in between.</p>
+</section>
+
+<section href="how" name="How does Struts work?">
+<p>Java Servlets are designed to handle requests made by Web browsers. Java ServerPages are designed to create dynamic Web pages that can turn billboard sites into live applications. Struts uses a special Servlet as a switchboard to route requests from Web browsers to the appropriate ServerPage. This makes Web applications much easier to design, create, and maintain.</p>
+</section>
+
+<section href="compat" name="Is Struts compatible with other Java technologies?">
+<p>Yes. Struts is committed to supporting industry standards. Our lead developer is a member of <a href="http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html">JSR052</a>, Sun's Expert group for developing a standard library of custom JSP tags. A primary design criteria is that Struts must be compatible with Sun's J2EE platform for corporate enterprises. In fact, Struts really acts as an integrator of Java technologies, so that they can be used in the &quot;real world&quot;.</p>
+</section>
+
+<section href="who" name="Who wrote Struts?">
+<p>Struts was created by Craig R. McClanahan, and donated to The Apache Software Foundation in May 2000. Craig is the primary developer of both Struts and <a href="http://jakarta.apache.org/tomcat/index.html">Tomcat 4</a>, the basis for the official reference implementation for a servlet 2.3 and JSP 1.2 container. With stable releases of Struts and Tomcat 4 in circulation, Craig is now the Specification Lead for <a href="http://jcp.org/jsr/detail/127.jsp">JavaServer Faces (JSR-127)</a>, and is the Web Layer Architect for the Java2 Enterprise Edition (J2EE) platform as a whole.</p>
+<p>There are now many active committers to the Struts project, working cooperatively from around the globe. Other Java developers are invited to <a href="helping.html#contribute">contribute to the project</a>. Struts is an <a href="http://jakarta.apache.org/">Apache Jakarta</a>  project, with the common mission to &quot;provide commercial-quality server solutions based on the Java Platform that are developed in an open and cooperative fashion&quot;. All told, 17 individual developers and committers contributed to the Struts 1.0 codebase.</p>
+</section>
+
+<section href="struts" name="Why is it called Struts?">
+<p>It's a reference to struts in the architectural sense, a reminder of the nearly invisible pieces that hold up buildings, houses, and bridges.</p>
+</section>
+
+<section href="license" name="How is Struts licensed?">
+<p>Struts is copyrighted software available under a &quot;free-to-use-license&quot; by The Apache Software Foundation. The license appears at the head of every source code file. A reference copy of the license is available <a href="http://www.apache.org/LICENSE-1.1">here</a>.</p>
+</section>
+
+<section href="usage" name="Can Struts be used in a commercial product?">
+<p>Yes. The only requirements you must meet are those listed in the Apache Software Foundation license, which is included at the top of each source file and in the file LICENSE in the top-level directory of the distribution.</p>
+<p>In addition, <a href="helping.html#bugs">contributions of patches, improved code, new features,</a> or even just requests for features are also welcome.</p>
+</section>
+
+<section href="credits" name="Do I have to credit Struts on my own website?">
+<p>You need to credit Struts if you <strong>redistribute your own framework</strong> based on Struts
+for other people to use. (See the <a href="http://www.apache.org/LICENSE">Apache License</a> for details.)
+But you do <strong>not</strong> need to credit Struts just because your web application utilizes the framework.
+It's the same situation as using the Apache HTTPD server or Tomcat. Not required if its just running your web site.
+Required if you've used the source code to create your own server that you are redistributing to other people.</p>
+</section>
+
+<section href="where" name="Where can I get a copy of Struts?">
+<p>The best place to download Struts is at <a href="http://jakarta.apache.org/struts/">jakarta.apache.org/struts</a>. The nightly builds are very stable, and recommended as the best place to start today.</p>
+</section>
+
+<section href="install" name="How do I install Struts?">
+<p>To develop applications with Struts, you can usually just add the Struts JAR file
+to your Java development environment. You can then start using the Struts classes as
+part of your own application. A blank Struts application (in the
+<code>webapps</code> directory, open <code>struts-blank.war</code>)
+is provided, which you can just copy to get a quick-start on your own brainchild.</p>
+<p>Since the full source code for Struts is available, we also provide
+<a href="../userGuide/installation.html">complete instructions</a>
+for compiling your own Struts JAR from scratch. (This is actually easier than it looks!)</p>
+<p>Your Struts application can usually be deployed using a standard WAR file. In most
+cases, you simply deposit the WAR file on your application server, and it is installed
+automatically. If not, step-by-step installation instructions for
+<a href="../userGuide/installation.html#Containers">various servlet
+containers</a> are available.</p>
+</section>
+
+<section href="jar" name="When do I need &quot;struts.jar&quot; on my classpath?">
+<p>When you are compiling an application that uses the Struts classes, you must have the &quot;struts.jar&quot; on the classpath your <strong>compiler</strong> sees -- it does not <em> have</em> to be on your CLASSPATH environment variable.</p>
+<p>Why is that an important distinction? Because if you are using a servlet container on your development machine to test your application, the &quot;struts.jar&quot; <strong>must not</strong> be on your CLASSPATH environment variable when running the container. (This is because each Web application must also have their own copy of the Struts classes, and the container will become confused if it is on the environment path as well.)</p>
+<p>There are several general approaches to this issue:</p>
+<ul>
+<li><strong>Use ANT</strong> for building your projects -- it can easily assemble classpaths for the compiler.  (This is how Struts itself is  built, along with Tomcat and most other Java-based projects).</li>
+<li><strong>Use an IDE</strong> where you can configure the "class path" used  for compilation independent of the CLASSPATH environment  variable.</li>
+<li><strong>Use a shell script</strong> that temporarily adds struts.jar  to the classpath just for compilation, for example<br/>
+<em>javac -classpath /path/to/struts.jar:$CLASSPATH $@</em></li>
+</ul>
+</section>
+
+<section href="tests" name="Does Struts include its own unit tests?">
+<p>
+Struts currently has two testing environments, to reflect the fact that
+some things can be tested statically, and some really need to be done in
+the environment of a running servlet container.</p>
+<p>
+For static unit tests, we use the <a href="http://www.junit.org">JUnit framework</a>.
+The sources for these tests are in the "src/test"
+hierarchy in the Subversion repository, and are executed via the "test.junit"
+target in the top-level build.xml file.  Such tests are focused on the
+low-level functionality of individual methods, are particularly
+suitable for the static methods in the org.apache.struts.util utility
+classes.  In the test hierarchy, there are also some "mock object" classes
+(in the org.apache.struts.mock package) so that you can package up things
+that look like servlet API and Struts API objects to pass in as arguments
+to such tests.</p>
+<p>
+Another valuable tool is
+<a href="http://sourceforge.net/projects/strutstestcase/">Struts TestCase</a>
+which provides a useful harness for Action classes that can be used with JUnit or
+<a href="http://jakarta.apache.org/cactus">Cactus</a>.
+</p>
+</section>
+
+<section href="requests" name="If the framework doesn't do what I want, can I request that a feature be added?">
+<p>
+First, it's important to remember that Struts is an all-volunteer project.
+We don't charge anyone anything to use Struts.
+Committers and other developers work on Struts because they need to use it with their own applications.
+If others can use it too, that's "icing on the cake".
+If you submit a patch for a feature that a Committer finds useful, then that Committer may choose to volunteer his or her time to apply the patch.
+If you just submit an idea without a patch, it is much less likely to be added (since first someone else has to volunteer their time to write the patch).
+</p>
+<p>
+We are grateful for any patches, and we welcome new ideas, but the best way to see that something gets added to the framework is to do as much of the work as you can, rather than rely on the "kindness of strangers". Worst case, you can apply the patch to your copy of Struts and still use the feature in your own application. (Which is what open source is ~really~ all about.)
+</p>
+</section>
+
+<section href="help" name="Where can I get help with Struts?">
+<p>The Struts package comes complete with a
+<a href="../userGuide/index.html">Users Guide</a> to
+introduce people to the framework and its underlying technologies. Various components
+also have their own in-depth Developers Guide, to cover more advanced topics. Comprehensive
+<a href="../api/index.html">Javadocs</a> are included
+along with the <strong>full source code</strong>. For your convenience, these are bundled together as
+a self-installing application. The <code>struts-documentation.war</code> is the same
+bundle that is deployed as the
+<a href="http://jakarta.apache.org/struts/">Struts Web site</a>.
+</p>
+<p>
+The
+<a href="http://jakarta.apache.org/site/mail.html">Strut's mailing list</a> is also
+very active, and welcomes posts from new users. Before posting a new question, be
+sure to consult the
+<a href="http://www.mail-archive.com/struts-user%40jakarta.apache.org/">
+<strong>MAILING LIST ARCHIVE</strong></a> and the very excellent
+<a href="http://www.tuxedo.org/~esr/faqs/smart-questions.html">
+How To Ask Questions The Smart Way</a> by Eric Raymond. Please do be sure
+to <a href="http://expita.com/nomime.html">turn off HTML</a> in your
+email client before posting.
+</p>
+</section>
+
+<section href="support" name="Is commercial support available?">
+<p>There is no official, commercial support for Struts, though third parties may offer different degrees of support. </p>
+</section>
+
+<section href="providers" name="Are there ISPs that will host my Struts application?">
+<p>For a listing of some Java and Struts ISPs, visit the <a href="http://struts.sf.net/commnity/index.html">Struts Community Resources</a> area on SourceForge.</p>
+</section>
+
+<section href="turbine" name="What's the difference between Struts and Turbine? What's the difference between Struts and Expresso?">
+<p>
+If you are starting from scratch, packages like
+<a href="http://jakarta.apache.org/turbine">Turbine</a> and
+<a href="http://jcorporate.com">Expresso</a>
+can be very helpful since they try to provide all of the basic services that your team is likely to need.
+Such services include things like data persistence and logging.
+</p>
+<p>
+If you are not starting from scratch, and need to hook up your web application to an existing infrastructure, then "plain vanilla" Struts can be a better choice.
+The core Struts framework does not presuppose that you are using a given set of data persistence, presentation, or logging tools.
+Anything goes =:0)
+</p>
+<p>
+Compared to other offerings, Struts endeavors to be a minimalist framework.
+We try leverage existing technologies whenever we can and provide only the missing pieces you need to combine disparate technologies into a coherent application.
+This is great when you want to select your own tools to use with Struts.
+But, if you prefer a more integrated infrastructure, then packages like Turbine or Expresso (which uses Struts) are perfectly good ways to go.
+</p>
+<p>See also</p>
+<ul>
+<li>&lt; <a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03206.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03206.html</a> &gt;</li>
+<li>&lt; <a href="http://www.mail-archive.com/general@jakarta.apache.org/msg00495.html">http://www.mail-archive.com/general@jakarta.apache.org/msg00495.html</a> &gt;</li>
+<li>&lt; <a href="http://jakarta.apache.org/velocity/ymtd/ymtd.html">http://jakarta.apache.org/velocity/ymtd/ymtd.html</a> &gt;</li>
+</ul>
+</section>
+
+<section href="taglibs" name="Why aren't the Struts tags maintained as part of the Jakarta Taglibs project?">
+<p>Development of both products began about the same time. Leading up to the release of 1.0, it was thought better to continue to develop the taglibs alongside the controller. Now that 1.0 is out, the JavaServer Pages Standard Taglib is in active development. Once work on JSTL stabilizes, the Struts taglibs will be revisited. Tags which are not linked directly to the framework may be hosted at Jakarta Taglibs instead.</p>
+</section>
+
+<section href="xhtml" name="Are the Struts tags XHTML compliant?">
+<p>If you use an &lt;html:html xhtml="true&gt; or &lt;html:xhtml/&gt; element on your page, the tags
+will render as XHTML (since Struts 1.1). </p>
+</section>
+
+<section href="wml" name="Will the Struts tags support other markup languages such as WML">
+<p>
+Struts itself is markup neutral. The original Struts taglibs are only one example of how
+presentation layer components can access the framework. The framework objects are exposed
+through the standard application, session, and request contexts, where any Java component in
+the application can make use of them.
+</p>
+
+<p>Markup extensions that use Struts are available for
+<a href="http://jakarta.apache.org/velocity">Velocity</a> and
+<a href="http://www.openroad.ca/opencode/">XLST</a>, among others.
+A new Struts tag library for
+<a href="#jsf">Java Server Faces</a> is also in development.
+</p>
+
+<p>For more about using WAP/WML with Struts see the article
+<a href="http://www.sys-con.com/pbdj/archives2/0904/hamboeck/">
+WAP up your EAserver</a>.
+</p>
+</section>
+
+<section href="jsf" name="What about JSTL and JavaServer Faces?">
+    <p>
+       JSTL, the <a href="http://java.sun.com/products/jsp/jstl/">
+       JavaServer Standard Tag Library</a>, is a set of JSP tags that
+       are designed to make it easier to develop Web applications.
+       <a href="http://java.sun.com/j2ee/javaserverfaces/">JavaServer Faces</a>
+       (JSF) is a specification for a new technology that promises to make
+       it easier to write MVC applications, both for the Web and for the
+       desktop.
+    </p>
+<p>
+The inventor of Struts, Craig McClanahan, was a member of the
+expert group for the JavaServer Standard Tag Library (JSR 052) and
+is now the specification co-lead for JavaServer Faces (JSR 127). Both
+technologies are complementary to Struts.</p>
+<p>
+The mainstay of the Struts framework is the controller components, which
+can be used with any Java presentation technology. As new technologies
+become available, it is certain that new "glue" components will also
+appear to help these technologies work as well with Struts.
+    </p>
+    <p>
+        Struts originally came bundled with a set of custom JSP tags.
+        Today, several extensions are available to help
+        you use Struts with other popular presentation technologies, like
+        XSLT and Velocity. Likewise, extensions for JSTL and JSF are now available as well.
+    </p>
+<p>
+    The JSTL reference implementation is available through the
+    <a href="http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html">Jakarta Taglibs site</a>.
+    A JSTL taglibs for Struts,
+    <a href="../userGuide/building_view.html#struts-el"><strong>Struts-El</strong></a>,
+    is available and distributed with Struts beginning with the 1.1 release.
+</p>
+    <p>
+        Meanwhile, the JSF specification is still under development,
+        although an early-release reference implementation is available through the
+        <a href="http://java.sun.com/webservices/download.html">Java Web Services Developer Pack</a>.
+        An early-release JavaServer Faces taglib for Struts,
+        <a href="http://archive.apache.org/dist/jakarta/struts/old/release/struts-faces/">
+        <strong>Struts-Faces</strong></a>, is also in early release and available
+        through the nightly build.
+    </p>
+    <p>
+        For more about what JavaServer Faces means to the Struts community,
+        see the <a href="http://wiki.apache.org/struts/StrutsMoreAboutJSF">
+        StrutsMoreAboutJSF</a> wiki page.
+    </p>
+</section>
+
+<section href="ide" name="Is there a particularly good IDE to use with Struts">
+<p>
+Struts should work well with any development environment that you would like to use, as well as with any programmers editor. 
+The members of the Struts development team each use their own tools such as 
+<a href="http://www.gnu.org/software/emacs/emacs.html">Emacs</a>, 
+<a href="http://www.intellij.com/idea/">IDEA</a>, 
+<a href="http://www.eclipse.org/">Eclipse</a>, 
+and <a href="http://www.netbeans.org/">NetBeans</a>.
+</p>
+<p>
+At this writing, in the free zone, NetBeans had the edge with JSP editing, but Eclipse has more advanced refactoring features. 
+Eclipse is also a general-purpose IDE and can be used with non-Java projects.
+In the non-free zone, IDEA is highly regarded but costs money. (Of course, if *you* cost money, good tools are often a good investment.)
+</p>
+<p>
+See the <a href="../faqs/index.html">Howto Guides</a> for more about configuring IDEs to work with Struts.
+</p>
+</section>
+
+<section href="digest" name="Is there a digest for the User list?">
+<p>
+Yes. <a href="mailto:struts-user-digest-subscribe@jakarta.apache.org">send a blank message</a> to &lt; <a href="mailto:struts-user-digest-subscribe@jakarta.apache.org">struts-user-digest-subscribe@jakarta.apache.org</a>&gt;.
+</p>
+<p>
+If you are subscribed to the digest, you can also post to the list.
+Just be sure to send your post to the
+<a href="mailto:struts-user@jakarta.apache.org">user list</a> rather than trying to reply to the digest.
+</p>
+</section>
+
+<section href="newsgroup" name="Is there a Struts newsgroup?">
+<p>
+Not a usenet group, but the Struts User list can be accessed with your
+favorite newsgroup reader from the
+<a href="http://news.gmane.org/">GMane News Site</a>.  Subscribe to groups
+<code>gmane.comp.jakarta.struts.devel</code> for the developer list, or
+<code>gmane.comp.jakarta.struts.user</code> for the user list.
+</p>
+</section>
+
+<section href="mailbounce" name="Why didn't my posting show up on the user list?">
+<p>
+You must be subscribed to the <a href="mailto:struts-user-subscribe@jakarta.apache.org">user list</a>
+or <a href="mailto:struts-user-digest-subscribe@jakarta.apache.org">user digest</a> before posting
+(or use the <a href="http://news.gmane.org">GMane Newsgroups</a> instead).
+</p>
+</section>
+
+<section href="unsubscribe" name="How do I unsubscribe from the mailing list?">
+<p>
+<strong>From the email account used to subscribe to the list,</strong> <a href="mailto:struts-user-unsubscribe@jakarta.apache.org">send a blank message</a> to &lt; <a href="mailto:struts-user-unsubscribe@jakarta.apache.org">struts-user-unsubscribe@jakarta.apache.org</a>&gt;.
+</p>
+<p>
+If you are receiving the digest, you must send a blank email to
+&lt;<a href="mailto:struts-user-digest-unsubscribe@jakarta.apache.org">struts-user-unsubscribe@jakarta.apache.org</a>&gt;
+instead.
+</p>
+</section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/faqs/netbeans.xml b/build-legacy/core/xdocs/faqs/netbeans.xml
new file mode 100644
index 0000000..9730bc1
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/netbeans.xml
@@ -0,0 +1,229 @@
+<?xml version="1.0"?>
+
+<document url="./ssl.xml">
+
+<properties>
+
+
+<title>How to setup a basic Struts project using Netbeans IDE - Apache Struts</title>
+
+</properties>
+
+<body>
+
+<section href="netbeans" name="How to setup a basic Struts project using Netbeans IDE"/>
+<section name="Legal Disclamer">
+
+Please read <a href="http://jakarta.apache.org/site/idedevelopers.html">this</a> first.<br/>
+<p>
+* DISCLAIMER - This simple How-To shows you one of many ways to setup a working project using<br/>
+the Struts framework.  This is mainly geared toward struts users who are new to Netbeans, and<br/> 
+don't want to spend a lot of time figuring out the differences between their old IDE (if any)<br/>
+and this one.<br/>
+<br/>
+I will also apologize ahead of time for the formatting of this page.<br/>
+</p>
+<br/>
+In this How-To, I will demonstrate (using Netbeans 3.4) how to setup, compile, and build
+a customized version of the struts-example.<br/> 
+</section>
+
+
+<section name="Let's get started">
+<ol>
+ <li>
+  Create a new project.<br/>
+  <img alt="" src="../images/how-to/netbeans/creating-project3.jpg"></img><br/><br/><br/>
+  <img alt="" src="../images/how-to/netbeans/creating-project4.jpg"></img><br/><br/><br/>
+  <img alt="" src="../images/how-to/netbeans/creating-project5.jpg"></img><br/><br/><br/>
+  <img alt="" src="../images/how-to/netbeans/creating-project6.jpg"></img><br/><br/><br/>
+  <img alt="" src="../images/how-to/netbeans/creating-project8.jpg"></img><br/><br/><br/>
+  </li>
+ <li>
+  Now let's create (or reuse) a directory to hold the project.
+  What I did was copy the struts-example.war from the Struts distribution
+  and extracted it (using Winzip) like this:
+  <br/>
+  <img alt="" src="../images/how-to/netbeans/directory.jpg"></img><br/><br/><br/>
+  </li>
+ <li>
+  Next we need to create a build.xml to build our project.  This file will sit in the root<br/>
+  directory of your project. (Actually, it doesn't matter where sits so long as you make <br/>
+  the appropriate changes to directories and such.)<br/>
+  <br/>
+  *Note - I will not spend any time here trying to convince you why you should be <br/>
+  using Ant to build your projects.  I guess I consider this to be obvious.<br/>
+  Here is the build.xml file I use for this demonstration (you MUST modify this <br/>
+  to use your environment):<br/>
+  <pre>
+  
+  &lt;project name="Struts Example" default="main" basedir="."&gt;
+  
+    &lt;!--  This is a basic build script, only the minimums here --&gt;
+    
+    &lt;!-- Tell ant to use my environment variables --&gt;
+    &lt;property environment="env"/&gt;
+  
+    &lt;property file="./build.properties"/&gt;
+  
+      &lt;property name="build.compiler"     value="modern"/&gt;
+      &lt;property name="build.dir"          value="./WEB-INF/classes" /&gt;
+      &lt;property name="src.dir"            value="./WEB-INF/src"/&gt;
+    &lt;property name="servlet.jar"        value="/Apache_Home/jakarta-servletapi-4/lib/servlet.jar"/&gt;
+      &lt;property name="war.file"              value="struts-example"/&gt;
+      &lt;property name="war.file.name"      value="${war.file}.war"/&gt;
+      &lt;property name="tomcat.home"       value="${env.CATALINA_HOME}"/&gt;
+      &lt;property name="deploy.dir"         value="${tomcat.home}/webapps"/&gt;
+  
+    &lt;path id="project.class.path"&gt;
+        &lt;fileset dir="./WEB-INF/lib/"&gt;
+            &lt;include name="**/*.jar"/&gt;
+        &lt;/fileset&gt;
+        &lt;pathelement path="${src.dir}"/&gt;
+        &lt;pathelement path="${servlet.jar}"/&gt;
+    &lt;/path&gt;
+  
+      &lt;target name="clean"&gt;
+          &lt;delete dir="${build.dir}" includeEmptyDirs="true" /&gt;
+      &lt;/target&gt;
+  
+  
+      &lt;target name="prep"&gt;
+          &lt;mkdir dir="${build.dir}"/&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="compile"&gt;
+        &lt;javac   srcdir="${src.dir}"
+                    destdir="${build.dir}"
+                    debug="on"
+                deprecation="on"&gt;
+          &lt;include name="**/*.java"/&gt;
+          &lt;classpath refid="project.class.path"/&gt;
+        &lt;/javac&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="cleanWebApp"&gt;
+        &lt;delete file="${deploy.dir}/${war.file.name}" /&gt;
+          &lt;delete  dir="${deploy.dir}/${war.file}" includeEmptyDirs="true" /&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="war"&gt;
+          &lt;war warfile="${war.file.name}" webxml="./WEB-INF/web.xml"&gt;
+                 &lt;fileset dir="./" includes="**/*.*" excludes="*.war, **/*.nbattrs, web.xml, **/WEB-INF/**/*.*, **/project-files/**/*.*"/&gt;
+                 &lt;webinf  dir="./WEB-INF"    includes="**/*" excludes="web.xml, **/*.jar, **/*.class"/&gt;
+                 &lt;lib     dir="./WEB-INF/lib"/&gt;
+                 &lt;classes dir="${build.dir}" includes="**/*.properties" /&gt;
+          &lt;/war&gt;
+      &lt;/target&gt;
+  
+      &lt;target name="deploy"&gt;
+          &lt;copy todir="${deploy.dir}"&gt;
+            &lt;fileset dir="./" includes="${war.file.name}"/&gt;
+          &lt;/copy&gt;
+      &lt;/target&gt;
+ 
+    &lt;target name="main" depends="clean, prep, cleanWebApp, compile, war"/&gt;
+  
+  &lt;/project&gt;
+  
+  </pre>
+  </li>
+  <li>
+  Build the project using Ant from the command line.<br/>
+  Here's what I get:
+  
+  <pre>
+  
+  C:\personal\development\Projects\struts-examples\struts-example>ant
+  Buildfile: build.xml
+  
+  clean:
+     [delete] Deleting directory C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\classes
+  
+  prep:
+      [mkdir] Created dir: C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\classes
+  
+  cleanWebApp:
+     [delete] Deleting: C:\Apache_Home\jakarta-tomcat-4.0.6\webapps\struts-example.war
+     [delete] Deleting directory C:\Apache_Home\jakarta-tomcat-4.0.6\webapps\struts-example
+  
+  compile:
+      [javac] Compiling 22 source files to C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\classes
+      [javac] C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\src\org\apache\struts\webapp\example\memory\MemoryDatabasePlugIn.java:78: warning: org.apache.struts.config.ApplicationConfig in org.apache.struts.config has been deprecated
+      [javac] import org.apache.struts.config.ApplicationConfig;
+      [javac]                                 ^
+      [javac] C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\src\org\apache\struts\webapp\example\memory\MemoryDatabasePlugIn.java:185: warning: org.apache.struts.config.ApplicationConfig in org.apache.struts.config has been deprecated
+      [javac]     public void init(ActionServlet servlet, ApplicationConfig config)
+      [javac]                                             ^
+      [javac] C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\src\org\apache\struts\webapp\example\memory\MemoryDatabasePlugIn.java:185: warning: init(org.apache.struts.action.ActionServlet,org.apache.struts.config.ApplicationConfig) in org.apache.struts.action.PlugIn has been deprecated
+      [javac]     public void init(ActionServlet servlet, ApplicationConfig config)
+      [javac]                 ^
+      [javac] C:\personal\development\Projects\struts-examples\struts-example\WEB-INF\src\org\apache\struts\webapp\example\memory\MemoryDatabasePlugIn.java:185: warning: org.apache.struts.config.ApplicationConfig in org.apache.struts.config has been deprecated
+      [javac]     public void init(ActionServlet servlet, ApplicationConfig config)
+      [javac]                                             ^
+      [javac] 4 warnings
+  
+  war:
+        [war] Building war: C:\personal\development\Projects\struts-examples\struts-example\struts-example.war
+  
+  main:
+  
+  BUILD SUCCESSFUL
+Total time: 11 seconds
+  </pre>  
+  <br/>
+ </li>
+ <li>
+  If it did not build for you, verify that the external jars (external to this project) are 
+  specified correctly.<br/>
+  </li>
+  <li>
+  Now we can finish setting up our Netbeans project<br/><br/>
+  Mount the directory where we extracted the example and where we ran the build:<br/>
+  <img alt="" src="../images/how-to/netbeans/building1.jpg"></img><br/><br/><br/>
+  <img alt="" src="../images/how-to/netbeans/building2.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+  If specified correctly, Netbeans will parse the build.xml automatically and will use <br/>
+  (mount jars) the resources that you've declared for building.<br/>
+    <img alt="" src="../images/how-to/netbeans/building3.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+    I usually get rid of the additional mounted directory under /WEB-INF/classes.  <br/>
+    Since everything there gets overwritten with each build, I don't usually need to<br/> 
+    see this (or possibly make changes in the wrong place)<br/>
+    <img alt="" src="../images/how-to/netbeans/building4.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+    In order for Netbeans to understand the package structure for our source code, we need<br/>
+    to mount all source directories directly.  <br/><br/>
+    *Note - Some IDEs will do this automatically <br/>
+    (Eclipse) or can be configured from the project config file (JBuilder)<br/>
+    <img alt="" src="../images/how-to/netbeans/building5.jpg"></img><br/><br/><br/>
+    <img alt="" src="../images/how-to/netbeans/building6.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+    Use your source mount point to add/edit/delete your .java files<br/>
+    <img alt="" src="../images/how-to/netbeans/building7.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+    Using the initial mount point, expand until you can right-click on the build.xml file (or one<br/>
+    of the targets) and build the project<br/>
+    <img alt="" src="../images/how-to/netbeans/building8.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+    If you receive errors from Netbeans (choking on the XML parse), don't worry, I did too.<br/>
+    I always call ant on the command line anyway, so I don't worry too much about the IDE's <br/>
+    internal XML jars.<br/>
+    <!--[:TODO:] finish this section with solution to Netbeans ant/xml incompatibility woes--><br/>
+    <img alt="" src="../images/how-to/netbeans/building8.jpg"></img><br/><br/><br/>
+  </li>
+  <li>
+    Feel free to change the code as you like, and then build and deploy your new app.
+  </li>
+  
+</ol>
+
+</section>
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/faqs/newbie.xml b/build-legacy/core/xdocs/faqs/newbie.xml
new file mode 100644
index 0000000..046f90c
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/newbie.xml
@@ -0,0 +1,1317 @@
+<?xml version="1.0"?>
+<document url="./newbie.xml">
+<properties>
+<title>Newbie FAQ - Apache Struts</title>
+</properties>
+<body>
+<section href="faq" name="Newbie FAQ"/>
+
+<section href="contents" name="Index">
+
+    <p>
+    Here are answers to the most common questions people ask when using
+    Struts on their first project.
+    <strong>For an in-depth, searchable FAQ, visit our friends at
+    <a href="http://www.jguru.com/faq/home.jsp?topic=Struts">JGuru</a>.</strong>
+    </p>
+
+    <ul>
+
+    <li>
+    <a href="#reload">Why was reload removed from Struts 1.1?</a>
+    </li>
+
+    <li>
+    <a href="#modules">What is a modular application? What does
+    module-relative mean?</a>
+    </li>
+
+    <li>
+    <a href="#naming">Why are some of the class and element names
+    counter-intuitive?</a>
+    </li>
+
+    <li>
+    <a href="#actionForms">Whither ActionForms?</a>
+    </li>
+
+    <li>
+    <a href="#actionFormInterface">Why is ActionForm a base class rather than an interface?</a>
+    </li>
+
+    <li>
+    <a href="#multiple">Can I use multiple HTML form elements with the same
+    name?</a>
+    </li>
+
+    <li>
+    <a href="#multipleSubmits">Can I have multiple submit buttons on the same
+    form?</a>
+    </li>
+
+    <li><a href="#checkbox">Why are my checkboxes not being set from ON to
+    OFF?</a>
+    </li>
+
+    <li><a href="#focus">Why doesn't the focus feature on the &lt;html:form>
+    tag work in every circumstance?</a>
+    </li>
+
+    <li>
+    <a href="#javascript.submit">How do I use JavaScript to submit a form? </a>
+    </li>
+
+    <li>
+    <a href="#javascript">How do I use JavaScript to ... </a>
+    </li>
+
+    <li>
+    <a href="#reset">Do I need to implement reset and set all my form
+    properties to their initial values?</a>
+    </li>
+
+    <li>
+    <a href="#scriptlets">Can't I just create some of my JavaBeans in the JSP
+    using a scriptlet?</a>
+    </li>
+
+    <li>
+    <a href="#otherBeans">Can I use other beans or hashmaps with ActionForms?</a>
+    </li>
+
+    <li>
+    <a href="#tags">Why do the Struts tags provide for so little
+    formatting?</a>
+    </li>
+
+    <li>
+    <a href="#layout">Why don't the Struts taglibs offer more layout options?</a>
+    </li>
+
+
+    <li>
+    <a href="#link">Why does the &lt;html:link> tag URL-encode javascript and
+    mailto links?"</a>
+    </li>
+
+    <li>
+    <a href="#authenticate">How can I authenticate my users?</a>
+    </li>
+
+    <li>
+    <a href="#pager">How can I scroll through list of pages like the search
+    results in google?</a>
+    </li>
+
+    <li>
+    <a href="#minimization">Why does the option tag render selected="selected"
+    instead of just "selected"?
+    </a></li>
+
+    <li><a href="#jsp">Do I have to use JSPs with my application?</a></li>
+
+    <li>
+    <a href="#formbeans">Do ActionForms have to be true JavaBeans?</a>
+    </li>
+
+    <li>
+    <a href="#separate">Do I have to have a separate ActionForm bean
+    for every HTML form?</a>
+    </li>
+
+    <li>
+    <a href="#prepopulate">How can I prepopulate a form?</a>
+    </li>
+
+    <li>
+    <a href="#noForm">Can I have an Action without a form?</a>
+    </li>
+
+    <li>
+    <a href="#requiredif">Can you give me a simple example of using the requiredif Validator rule?</a>
+    </li>
+
+    <li>
+    <a href="#validate">When is the best time to validate input?</a>
+    </li>
+
+    <li>
+    <a href="#avoidValidate">How can I avoid validating a form before data is entered?</a>
+    </li>
+
+    <li>
+    <a href="#wizard">How can I create a "wizard" workflow?</a>
+    </li>
+
+    <li>
+    <a href="#chaining">How can I "chain" Actions?</a>
+    </li>
+
+    </ul>
+
+    <p>
+    If you like to <a href="helping.html">contribute</a>,
+    there is a list of <a href="#undocumented"> undocumented questions</a>
+    at the end of this page.
+    </p>
+
+</section>
+
+<section href="reload" name="Why was reload removed from Struts 1.1?">
+
+<p>
+The problem with ReloadAction was that Struts was trying to act like a
+container, but it couldn't do a proper job of it. For example, you
+can't reload classes that have been modified, or (portably) add new
+classes to a running web application (even if the container supported it).
+</p>
+
+<p>
+Meanwhile, as 1.1 was being developed, work progressed on things
+like Tomcat's reload command via the Manager webapp. This feature allows
+you to quickly reload-on-demand, complete with saving and restoring your
+session). It started to make even less sense for Struts to half-implement
+a feature that containers are implementing fully.
+</p>
+
+<p>
+A more minor point is that freezing the configuration information at application
+startup time allows Struts to safely access the mapping information without
+bothering with synchronization. The "startup-only" strategy creates a modest
+but real improvement in performance for all users.
+</p>
+
+<p>So, ReloadAction is not supported in 1.1 for two reasons:</p>
+
+<ul>
+<li>
+    It never did let you reload everything that you would really
+    want to -- particularly changed classes -- so many people
+    ended up having to reload the webapp anyway.
+</li>
+<li>
+    Containers are starting to offer reload-on-demand features
+    which does the same thing as the Struts ReloadAction, only better.
+</li>
+<li>
+    Not supporting ReloadAction lets Struts avoid doing synchronization
+    locks around all the lookups (like figuring out which action to use,
+    or the destination of an ActionForward) so applications can run a
+    little faster.
+</li>
+</ul>
+
+<p>
+Of course, if someone came up with an implementation that solved these
+problems without creating any others, we would not be opposed to including
+a new ReloadAction.
+</p>
+
+</section>
+
+<section href="modules" name="What is a modular application? What does module-relative mean?">
+
+<p>
+Since Struts 1.1, the framework supports multiple application modules. All applications have at
+least one root, or default, module. Like the root directory in a file system, the default application
+has no name. (Or is named with an empty string, depending your viewpoint.) Developing an application
+with only a default module is no different from how applications were developed under Struts 1.0.
+Since Struts 1.1, you can add additional modules to your application, each of which can have their
+own configuration files, messages resources, and so forth. Each module is developed in the same way as
+the default module. Applications that were developed as a single module can added to a multiple
+module application, and modules can promoted to a standalone application without change. For more
+about configuring your application to support multiple modules, see
+<a href="../userGuide/configuration.html#dd_config_modules">Configuring Applications</a> in the
+User Guide.
+</p>
+
+<p>
+But to answer the question =:0), a modular application is a Struts application that uses more than
+one module. Module-relative means that the URI starts at the application-module level, rather than at
+the application-context level, or the absolute-URL level.
+</p>
+<ul>
+<li>Absolute URL: http://localhost/myApplication/myModule/myAction.do</li>
+<li>context-relative: /myModule/myAction.do</li>
+<li>module-relative: /myAction.do</li>
+</ul>
+
+</section>
+
+<section href="naming" name="Why are some of the class and element names counter-intuitive?">
+<p>
+The framework grew in the telling and as it evolved some of the names
+drifted.
+</p>
+<p>The good thing about a nightly build, is that everything becomes
+available to the community as soon as it is written. The bad thing about
+a nightly build is that things like class names get locked down early and
+then become difficult to change.
+</p>
+</section>
+
+
+<section href="actionForms" name="Wither ActionForms?">
+<p>
+<a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19281.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19281.html</a><br/>
+<a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19338.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg19338.html</a><br/>
+<a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg20833.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg20833.html</a><br/>
+</p>
+</section>
+
+
+<section href="actionFormInterface" name="Why is ActionForm a base class rather than an interface?">
+<p>
+The MVC design pattern is very simple to understand but much more difficult
+to live with.  You just need this little bit of Business Logic in the View
+logic or you need just that little bit of View logic in the Business tier and
+pretty soon you have a real mess.
+</p>
+<p>
+Making ActionForm a class takes advantage of the single
+inheritance restriction of Java to it makes it more difficult for people to do
+things that they should not do.
+</p>
+<p>
+ActionForms implemented as interfaces encourage making the property types match
+the underlying business tier instead of Strings, which violates one of the
+primary purposes for ActionForms in the first place (the ability to reproduce
+invalid input, which is a fundamental user expectation).
+ActionForms as an interface would also encourage using existing DAO objects as
+ActionForms by adding ‘implements ActionForm’ to the class.  This violates
+the MVC design pattern goal of separation of the view and business logic.
+</p>
+<p>
+Since the goal of struts is to enforce this separation, it just makes more sense
+for Struts to own the ActionForm.
+</p>
+</section>
+
+<section href="JavaBeans" name="Do ActionForms have to be true JavaBeans?">
+<p>
+The utilities that Struts uses (Commons-BeanUtils since 1.1) require that ActionForm properties follow
+the JavaBean patterns for mutators and accessors (get*,set*,is*). Since Struts uses the Introspection API
+with the ActionForms, some containers may require that all the JavaBean patterns be followed, including
+declaring "<code>implements Serializable</code>" for each subclass. The safest thing is to review the
+<a href="../userGuide/preface.html#javabeans">JavaBean specification</a> and follow all the prescribed patterns.</p>
+</section>
+
+
+<section href="multiple" name="Can I use multiple HTML form elements with the same name?">
+<p>
+Yes. Define the element as an array and Struts will autopopulate it like any other.
+</p>
+<pre>
+<code>
+private String[] id= {};
+public String[] getId() { return this.id; }
+public void setItem(String id[]) {this.id = id;}
+</code>
+</pre>
+<p>
+And so forth
+</p>
+</section>
+
+
+<section href="multipleSubmits" name="Can I have multiple submit buttons on the same form?">
+<p>
+<strong>Yes</strong>.  The issue is that only one action class can be
+associated with a single form. So the real issue is how do I decode
+multiple submit types to a single <code>Action</code> class.
+There is more than one way to achieve this functionality.</p>
+<p>
+The way that is suggested by struts is right out of the javadoc for
+<a href="../api/org/apache/struts/actions/LookupDispatchAction.html">
+<code>LookupDispatchAction</code></a>.
+Basically, <code>LookupDispatchAction</code> is using the keys from
+<code>ApplicationProperties.resources</code> as keys to a map of actions
+available to your <code>Action</code> class.  It uses
+<a href="http://java.sun.com/j2se/1.3/docs/guide/reflection/">reflection</a> to
+decode the request and invoke the proper action.  It also takes advantage of
+the struts <a href="../userGuide/struts-html.html#submit">
+<code>&lt;html:submit&gt;</code></a> tags and is straight forward to implement.</p>
+<p>
+You can roll your own with JavaScript events and <code>javascript:void
+(document.forms["myform"].submit)</code> on any html element.  This gives you
+control of how you want your page to look.  Again you
+will have to decode the expected action in the <code>execute</code> method of
+your action form if you choose this route.</p>
+</section>
+
+
+<section href="focus" name="Why doesn't the focus feature on the &lt;html:form> tag work in every circumstance?">
+<p>
+Unfortunately, there is some disagreement between the various browsers, and different versions of the same browser, as to how the focus can be set.
+The &lt;html:form> tag provides a quick and easy JavaScript that will set the focus on a form
+for most versions of most browsers.
+If this feature doesn't work for you, then you should set the focus using your own JavaScript.
+The focus feature is a convenient "value-add" -- not a core requirement of the tag.
+If you do come up with a JavaScript that provides the final solution to this project,
+please post your patch to this <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=13454">Bugzilla ticket</a>.
+</p>
+</section>
+
+
+<section href="checkbox" name="Why are my checkboxes not being set from ON to OFF?">
+<p>
+A problem with a checkbox is that the browser will only include it in the request
+when it is checked. If it is not checked, the HTML specification suggests that it
+not be sent (i.e. omitted from the request). If the value of the checkbox is being
+persisted, either in a session bean or in the model, a checked box can never
+unchecked by a HTML form -- because the form can never send a signal to uncheck
+the box. The application must somehow ascertain that since the element was not
+sent that the corresponding value is unchecked.
+</p>
+<p>
+The recommended approach for Struts applications is to use the reset method in the
+ActionForm to set all properties represented by checkboxes to null or false. The
+checked boxes submitted by the form will then set those properties to true. The
+omitted properties will remain false. Another solution is to use radio buttons
+instead, which always submit a value.
+</p>
+<p>
+It is important to note that the HTML specification recommends this same
+behavior whenever a control is not "successful". Any blank element in a HTML
+form is not guaranteed to submitted. It is therefor very important to set the
+default values for an ActionForm correctly, and to implement the reset method
+when the ActionForm might kept in session scope.
+</p>
+</section>
+
+<section href="javascript.submit" name="Can I use JavaScript to submit a form?">
+<p>
+    You can submit a form with a link as below.
+    BTW, the examples below assume you are in an &lt;html:form&gt; block and 'myForm'
+    is picked up from the struts-config.xml name field of the action.
+</p>
+<pre><code>
+    &lt;a href='javascript:void(document.forms["myForm"].submit()&gt;My Link&lt;/a&gt;
+</code></pre>
+<p>
+    Now the trick in the action is to decode what action you intend to perform.
+    Since you are using JavaScript, you could set a field value and look for it in
+    the request or in the form.
+</p>
+<p>
+    ... html/javascript part ...
+</p>
+<pre><code>
+        &lt;input type='hidden' value='myAction' /&gt;
+        &lt;input type='button' value='Save Meeeee'
+            onclick='document.forms["myForm"].myAction.value="save";
+                     document.forms["myForm"].submit();' /&gt;
+        &lt;input type='button' value='Delete Meeeee'
+            onclick='document.forms["myForm"].myAction.value="delete";
+                     document.forms["myForm"].submit();' /&gt;
+</code></pre>
+<p>
+    ... the java part ...
+</p>
+<pre><code>
+        class MyAction extends ActionForm implements Serializable {
+
+            public ActionForward execute (ActionMapping map, ActionForm form,
+                HttpServletRequest req, HttpServletResponse) {
+
+                    String myAction = req.getParameter("myAction");
+
+                    if (myAction.equals("save") {
+                           // ...  save action  ...
+                    } else if (myAction.equals("delete") {
+                           // ...  delete action  ...
+                    }
+                }
+            }
+        }
+</code></pre>
+<p>
+    This is just one of many ways to achieve submitting a form and decoding the
+    intended action.  Once you get used to the framework you will find other ways
+    that make more sense for your coding style and requirements.  Just remember
+    this example is completely non-functional without JavaScript.
+</p>
+<p>
+    Here is a link
+    which utilizes the LookupDispatch action to submit forms with multiple actions
+    without javascript: <a href="http://husted.com/struts/tips/003.html">http://husted.com/struts/tips/003.html</a>
+</p>
+
+</section>
+
+<section href="javascript" name="How do I use JavaScript to ...">
+
+    <p>
+    Struts is mainly a server-side technology.
+    We bundled in some JSP tags to expose the framework components to your
+    presentation page, but past that, the usual development process applies.
+    </p>
+
+    <p>
+    Interactive pages require the use of JavaScript.
+    (That's why it was invented.)
+    If you want things popping up or doing this when they click that,
+    you are outside the scope of Struts and back into the web
+    development mainstream.
+    </p>
+
+    <p>
+    You use JavaScript with Struts the same way you use with any presentation
+    page.
+    Since JavaScript is a client-side technology, you can use simple relative
+    references to your scripts.
+    If you need to fire a JavaScript from a HTML control, the Struts HTML tags
+    have properties for the JavaScript events.
+    </p>
+
+    <p>
+    A very good JavaScript resource is Matt Kruse's site at
+    <a href="http://www.mattkruse.com/javascript/">
+    http://www.mattkruse.com/javascript/</a>
+    </p>
+
+</section>
+
+<section href="reset" name="Do I need to implement reset and set all my form properties to their initial values?">
+<p>
+No.
+You need to set checkbox properties to false if the ActionForm is being retained in session scope.
+This is because an unchecked box does not submit an attribute.
+Only checked boxes submit attributes.
+If the form is in session scope, and the checkbox was checked, there is no way to turn it back off without the reset method.
+Resetting the properties for other controls, or for a request scope form, is pointless.
+If the form is in request scope, everything already just started at the initial value.
+</p>
+</section>
+
+
+<section href="scriptlets" name="Can't I just create some of my JavaBeans in the JSP using a scriptlet?">
+<p>
+Struts is designed to encourage a
+<a href="http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html">
+Model 2/MVC architecture</a>. But there is nothing that prevents you from using Model 1
+techniques in your JavaServer Pages, so the answer  to the question is "Yes, you can".
+</p>
+<p>
+Though, using Model 1 techniques in a Struts application does go against the grain.
+The approach recommended by most Struts developers is to create and populate whatever
+objects the view may need in the Action, and then forward these through the request.
+Some objects may also be created and stored in the session or application context,
+depending on how they are used.
+</p>
+<p>
+Likewise, there is nothing to prevent you from using scriptlets along with JSP
+tags in your pages. Though, many Struts developers report writing very complex
+scriplet-free applications and recommend the JSP tag approach to others.
+</p>
+<p>
+For help with Model 1 techniques and scriptlets, you might consider joining the
+<a href="http://archives.java.sun.com/jsp-interest.html">Javasoft JSP-interest
+mailing list</a>, where there are more people still using these approaches.
+</p>
+</section>
+
+
+<section href="otherBeans" name="Can I use other beans or hashmaps with ActionForms?">
+    <p>
+    Yes. There are several ways that you can use other beans or hashmaps with ActionForms.
+    </p>
+    <ul>
+    <li>
+        ActionForms can have other beansor hashmaps as properties
+    </li>
+    <li>
+        "Value Beans" or "Data Transfer Objects" (DTOs) can be used independently of
+        ActionForms to transfer data to the view
+    </li>
+    <li>
+        ActionForms can use Maps to support "dynamic" properties (since Struts 1.1)
+    </li>
+    </ul>
+    <p>
+    ActionForms (a.k.a. "form beans") are really just Java beans (with a few
+    special methods) that Struts creates and puts into session or request scope for you.
+    There is nothing preventing you from using other beans, or including
+    them in your form beans. Here are some examples:
+    </p>
+    <p>
+    <em>Collections as properties</em> Suppose that you need to display a pulldown list of
+    available colors on an input form in your application. You can include a string-valued
+    <code>colorSelected</code> property in your <code>ActionForm</code> to represent the user's
+    selection and a <code>colorOptions</code> property implemented as a <code>Collection</code>
+    (of strings) to store the available color choices. Assuming that you have defined the getters
+    and setters for the <code>colorSelected</code> and <code>colorOptions</code> properties
+    in your <code>orderEntryForm</code> form bean, you can render the
+    pulldown list using:
+    </p>
+    <pre><code>
+    &lt;html:select property="colorSelected"&gt;
+      &lt;html:options property="colorOptions" name="orderEntryForm"/&gt;
+    &lt;/html:select&gt;
+    </code></pre>
+    <p>
+    The list will be populated using the strings in the <code>colorOptions</code>
+    collection  of the <code>orderEntryForm</code> and the value that the user selects
+    will go into the <code>colorSelected</code> property that gets posted to the subsequent
+    <code>Action</code>. Note that we are assuming here that the <code>colorOptions</code>
+    property of the <code>orderEntryForm</code> has already been set.
+    </p>
+    <p>
+    See <a href="#prepopulate">How can I prepopulate a form?</a> for instructions on how to set
+    form bean properties before rendering edit forms that expect properties to be pre-set.
+    </p>
+    <p>
+    <em>Independent DTO</em> An <code>Action</code> that retrieves a list of open orders (as an
+    <code>ArrayList</code> of <code>Order</code> objects) can use a DTO independently of any
+    form bean to transfer search results to the view. First, the Action's
+    <code>execute</code> method performs the search and puts the DTO into the request:
+    </p>
+    <pre><code>
+    ArrayList results = businessObject.executeSearch(searchParameters);
+    request.setAttribute("searchResults",results);
+    </code></pre>
+    <p>
+    Then the view can iterate through the results using the "searchResults" request key to
+    reference the DTO:
+`   </p>
+    <pre><code>
+    &lt;logic:iterate id="order" name="searchResults" type="com.foo.bar.Order"&gt;
+        &lt;tr&gt;&lt;td&gt;&lt;bean:write name="order" property="orderNumber"/&gt;&lt;td&gt;
+            &lt;td&gt;..other properties...&lt;/td&gt;&lt;/tr&gt;
+    &lt;/logic:iterate&gt;
+    </code></pre>
+    <p>
+    See also: <a href="../userGuide/building_controller.html#map_action_form_classes">Map-Backed ActionForms</a> (since Struts 1.1)
+    </p>
+</section>
+
+
+<section href="tags" name="Why do the Struts tags provide for so little formatting?">
+<p>
+<em>The Struts tags seem to provide only the most rudimentary functionality.
+Why is there not better support for date formatting and advanced string handling?</em>
+</p>
+<p>
+Three reasons:
+</p>
+<p>
+First, work started on the JSTL and we didn't want to duplicate the effort.
+</p>
+<p>
+Second, work started on Java Server Faces, and we didn't want to duplicate that effort either.
+</p>
+<p>
+Third, in a Model 2 application, most of the formatting can be handled in the ActionForms (or in the business tier),
+so all the tag has to do is spit out a string.
+This leads to better reuse since the same "how to format" code does not need to be repeated in every instance.
+You can "say it once" in a JavaBean and be done with it.
+</p>
+</section>
+
+<section href="layout" name="Why don't the Struts taglibs offer more layout options?">
+<p>
+Since the Struts tags are open source, you can extend them to provide whatever additional formatting you may need.
+If you are interested in a pre-written taglib that offers more layout options, see the
+<a href="http://struts.application-servers.com">struts-layout taglib</a>.
+</p>
+<p>
+In the same arena, there is a well regarded contributor taglib that can help you create
+<a href="http://sourceforge.net/projects/struts-menu/">Menus for your Struts applications</a>.
+</p>
+</section>
+
+<section href="link" name="Why does the &lt;html:link> tag URL-encode javascript and mailto links?">
+<p>
+The &lt;html:link> tag is not intended for use with client-side references like those used to launch Javascripts or email clients.
+The purpose of link tag is to interject the context (or module) path into the URI so that your server-side links are not dependent on your context (or module) name.
+It also encodes the link, as needed, to maintain the client's session on the server.
+Neither feature applies to client-side links, so there is no reason to use the &lt;html:link> tag.
+Simply markup the client-side links using the standard <a/> tag.
+</p>
+</section>
+
+<section href="authenticate" name="How can I authenticate my users?">
+<p>
+<a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24504.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg24504.html</a><br/>
+<a href="http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22949.html">http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22949.html</a>
+</p>
+</section>
+
+<section href="pager" name="How can I scroll through list of pages like the search results in google?">
+<p>Many Struts developers use the Pager from the JSPTags site.</p>
+<p><a href="http://jsptags.com/tags/navigation/pager/">http://jsptags.com/tags/navigation/pager/</a></p>
+</section>
+
+
+<section href="minimization" name="Why does the option tag render selected=selected instead of just selected?">
+<p>
+Attribute minimization (that is, specifying an attribute with no value) is
+a place where HTML violates standard XML syntax rules. This matters a lot
+for people writing to browsers that support XHTML, where doing so makes
+the page invalid.It's much better for Struts to use the expanded syntax,
+which works the same on existing browsers interpreting HTML, and newer
+browsers that expect XHTML-compliant syntax. Struts is following the
+behavior recommended by the <a href="http://www.w3.org/TR/xhtml1/#h-4.5">
+XHTML specification</a></p>
+</section>
+
+
+<section href="jsp" name="Do I have to use JSPs with my application?">
+
+    <p>
+    The short answer to this question is: No, you are not limited to
+    JavaServer Pages.
+    </p>
+
+    <p>
+    The longer answer is that you can use any type of presentation technology
+    which can be returned by a web server or Java container.
+    The list includes but is not limited to:
+    </p>
+
+    <ul>
+
+        <li>
+        JavaServer Pages,
+        </li>
+
+        <li>
+        HTML pages,
+        </li>
+
+        <li>
+        WML files,
+        </li>
+
+        <li>
+        Java servlets,
+        </li>
+
+        <li>
+        Velocity templates, and
+        </li>
+
+        <li>
+        XML/XLST
+        </li>
+
+    </ul>
+
+    <p>
+    Some people even mix and match apparently unrelated technologies,
+    like PHP, into the same web application.
+    </p>
+
+</section>
+
+<section href="formbeans" name="Do ActionForms have to be true JavaBeans?">
+
+    <p>ActionForms are added to a servlet scope (session or request)
+    as beans.  What this means is that, for certain functionality to
+    be available, your ActionForms will have to follow a few simple
+    rules.</p>
+
+    <p>First, your ActionForm bean must have a zero-arguments
+    constructor.  This is required because Struts must be able to
+    dynamically create new instances of your form bean class, while
+    knowing only the class name.  This is not an onerous restriction,
+    however, because Struts will also populate your form bean's
+    properties (from the request parameters) for you.</p>
+
+    <p>Second, the fields of your form bean are made available to the
+    framework by supplying public getter and setter methods that
+    follow the naming design patterns described in the JavaBeans
+    Specification.  For most users, that means using the following
+    idiom for each of your form bean's properties:</p>
+
+    <pre>
+        private {type} fieldName;
+
+        public {type} getFieldName() {
+            return (this.fieldName);
+        }
+
+        public void setFieldName({type} fieldName) {
+            this.fieldName = fieldName;
+        }
+    </pre>
+
+    <p><strong>NOTE</strong> - you <em>MUST</em> obey the capitalization
+    conventions shown above for your ActionForm properties to be recognized.
+    The property name in this example is "fieldName", and that must also be
+    the name of the input field that corresponds to this property.  A bean
+    property may have a "getter" method and a "setter" method (in a form bean,
+    it is typical to have both) whose name starts with "get" or "set",
+    followed by the property name with the first character capitalized.
+    (For boolean properties, it is also legal to use "is" instead of "get"
+    as the prefix for the getter method.)</p>
+
+    <p> Advanced JavaBeans users will know that you can tell the system
+    you want to use different names for the getter and setter methods, by
+    using a <code>java.beans.BeanInfo</code> class associated with your form
+    bean.  Normally, however, it is much more convenient to follow the
+    standard conventions.</p>
+
+    <p><strong>WARNING</strong> - developers might be tempted to use one of
+    the following techniques, but any of them will cause your property not
+    to be recognized by the JavaBeans introspection facilities, and therefore
+    cause your applications to misbehave:</p>
+    <ul>
+    <li><em>Using getter and setter method names that do not
+        match</em> - if you have a <code>getFoo()</code> method for your
+        getter, but a <code>setBar()</code> method for your setter, Java
+        will not recognize these methods as referring to the same property.
+        Instead, the language will think you have a read-only property named
+        "foo" and a write-only property named "bar".</li>
+    <li><em>Using more than one setter method with the same
+        name</em> - The Java language lets you "overload" methods, as long
+        as the argument types are different.  For example, you could have a
+        <code>setStartDate(java.util.Date date)</code> method and a
+        <code>setStartDate(String date)</code> method in the same class, and
+        the compiled code would know which method to call based on the
+        parameter type being passed.  However, doing this for form bean
+        properties will prevent Java from recognizing that you have a
+        "startDate" property at all.</li>
+    </ul>
+
+    <p>There are other rules to follow if you want other features of your
+    form beans to be exposed.  These include indexed attributes and mapped
+    attributes.  They are covered in detail in other areas of the Struts
+    documentation, in particular:</p>
+    
+    <a href="indexedprops.html">indexedprops.html</a>
+    
+
+    <p>For a complete explanation of what a JavaBean is, and everything it can
+    do, see the JavaBeans Specification (version 1.01) at:</p>
+    
+    <a href="http://java.sun.com/products/javabeans/docs/beans.101.pdf">
+    http://java.sun.com/products/javabeans/docs/beans.101.pdf</a>
+    
+
+</section>
+
+
+<section href="separate"
+      name="Do I have to have a separate ActionForm bean for every HTML form?">
+
+    <p>This is an interesting question.  As a newbie, it is a good
+    practice to create a new <code>ActionForm</code> for each action
+    sequence.  You can use <code>DynaActionForm</code>s to help reduce
+    the effort required, or use the code generation facilities of your
+    IDE.</p>
+
+    <p>Some issues to keep in mind regarding reuse of form beans
+    are as follows:</p>
+    <ul>
+    <li><em>Validation</em> - You might need to use different
+        validation rules depending upon the action that is currently
+        being executed.</li>
+    <li><em>Persistence</em> - Be careful that a form populated in
+        one action is not <strong>unexpectedly</strong> reused in a
+        different action.  Multiple <code>&lt;form-bean&gt;</code>
+        entries in <code>struts-config.xml</code> for the same
+        <code>ActionForm</code> subclass can help (especially if you
+        store your form beans in session scope).  Alternatively,
+        storing form beans in request scope can avoid unexpected
+        interactions (as well as reduce the memory footprint of your
+        application, because no server-side objects will need to be
+        saved in between requests.</li>
+    <li><em>Checkboxes</em> - If you do as recommended and reset
+        your boolean properties (for fields presented as checkboxes),
+        and the page you are currently displaying does not have a
+        checkbox for every boolean property on the form bean, the
+        undisplayed boolean properties will always appear to have a
+        <code>false</code> value.</li>
+    <li><em>Workflow</em> - The most common need for form bean
+        reuse is workflow.  Out of the box, Struts has limited support
+        for workflow, but a common pattern is to use a single form bean
+        with all of the properties for all of the pages of a workflow.
+        You will need a good understanding of the
+        environment (<code>ActionForm</code>s, <code>Action</code>s,
+        etc.) prior to being able to put together a smooth workflow
+        environment using a single form bean.</li>
+    </ul>
+
+    <p>As you get more comfortable, there are a few shortcuts you can
+    take in order to reuse your <code>ActionForm</code> beans.  Most of
+    these shortcuts depend on how you have chosen to implement your
+    <code>Action</code> / <code>ActionForm</code> combinations.</p>
+
+</section>
+
+
+<section href="prepopulate"
+         name="How can I prepopulate a form?">
+
+    <p>The simplest way to prepopulate  a form is to have an <code>Action</code>
+    whose sole purpose is to populate an <code>ActionForm</code> and forward
+    to the servlet or JSP to render that form back to the client.  A separate
+    <code>Action</code> would then be use to process the submitted form fields,
+    by declaring an instance of the same form bean name.</p>
+
+    <p>The <em>struts-example</em> example application that is shipped
+    with Struts illustrates this design pattern nicely.  Note the following
+    definitions from the <code>struts-config.xml</code> file:</p>
+    <pre>
+        ...
+        &lt;form-beans&gt;
+            ...
+            &lt;-- Registration form bean --&gt;
+            &lt;form-bean name="registrationForm"
+                       type="org.apache.struts.webapp.example.RegistrationForm"/&gt;
+            ...
+        &lt;/form-beans&gt;
+        ...
+        &lt;action-mappings&gt;
+            ...
+            &lt;-- Edit user registration --&gt;
+            &lt;action path="/editRegistration"
+                    type="org.apache.struts.webapp.example.EditRegistrationAction"
+                    name="registrationForm"
+                   scope="request"
+                validate="false"/&gt;
+            ...
+            &lt;-- Save user registration --&gt;
+            &lt;action path="/saveRegistration"
+                    type="org.apache.struts.webapp.example.SaveRegistrationAction"
+                    name="registrationForm"
+                   input="registration"
+                   scope="request"/&gt;
+            ...
+        &lt;/action-mappings&gt;
+    </pre>
+
+    <p>Note the following features of this approach:</p>
+    <ul>
+    <li>Both the <code>/editRegistration</code> and
+        <code>/saveRegistration</code> actions use the same form bean.</li>
+    <li>When the <code>/editRegistration</code> action is entered, Struts
+        will have pre-created an empty form bean instance, and passed it to
+        the <code>execute()</code> method.  The setup action is free to
+        preconfigure the values that will be displayed when the form is
+        rendered, simply by setting the corresponding form bean properties.
+        </li>
+    <li>When the setup action completes configuring the properties of the
+        form bean, it should return an <code>ActionForm</code> that points
+        at the page which will display this form.  If you are using the
+        Struts JSP tag library, the <code>action</code> attribute on your
+        &lt;html:form&gt; tag will be set to <code>/saveRegistration</code>
+        in order for the form to be submitted to the processing action.</li>
+    <li>Note that the setup action (<code>/editRegistration</code>) turns off
+        validation on the form that is being set up.  You will normally want
+        to include this attribute in the configuration of your setup actions,
+        because you are not planning to actually process the results -- you
+        simply want to take advantage of the fact that Struts will precreate
+        a form bean instance of the correct class for you.</li>
+    <li>The processing action (<code>/saveRegistration</code>), on the other
+        hand, leaves out the <code>validate</code> attribute, which defaults
+        to <code>true</code>.  This tells Struts to perform the validations
+        associated with this form bean before invoking the processing action
+        at all.  If any validation errors have occurred, Struts will forward
+        back to your input page (technically, it forwards back to an
+        <code>ActionForward</code> named "registration" in this case, because
+        the example webapp uses the <code>inputForward</code> attribute in the
+        <code>&lt;controller&gt;</code> element -- see the documentation
+        describing <code>struts-config.xml</code> for more information)
+        instead of calling your processing action.</li>
+    </ul>
+
+</section>
+
+<section href="noForm" name="Can I have an Action without a form?">
+<p>
+Yes. If your <code>Action</code> does not need any data and it does not need to make any
+data available to the view or controller component that it forwards to, it doesn't need
+a form. A good example of an <code>Action</code> with no <code>ActionForm</code> is the
+<code>LogoffAction</code> in the struts example application:</p>
+<pre>
+    &lt;action path="/logoff"
+        type="org.apache.struts.webapp.example.LogoffAction"&gt;
+      &lt;forward name="success" path="/index.jsp"/&gt;
+    &lt;/action&gt;
+</pre>
+<p>
+This action needs no data other than the user's session, which it can get from the
+<code>Request</code>, and it doesn't need to prepare any view elements for display,
+so it does not need a form.
+</p>
+
+    <p>
+    However, you cannot use the &lt;html:form&gt; <strong>tag</strong> without an ActionForm.
+    Even if you want to use the &lt;html:form&gt; tag with a simple Action that does not require input,
+    the tag will expect you to use some type of ActionForm, even if it is an empty subclass without any properties.
+    </p>
+
+</section>
+
+<section href="requiredif"
+         name="Can you give me a simple example of using the requiredif Validator rule?">
+     <p>First off, there's an even newer Validator rule called <code>validwhen</code>,
+     which is almost certainly what you want to use, since it is much easier and
+     more powerful.  It will be available in the first release after 1.1 ships.
+     The example shown below could be coded with validwhen as:</p>
+<pre>
+&lt;form name="medicalStatusForm"&gt;
+
+&lt;field
+    property="pregnancyTest" depends="validwhen"&gt;
+  &lt;arg0 key="medicalStatusForm.pregnancyTest.label"/&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;test&lt;/var-name&gt;
+    &lt;var-value&gt;((((sex == 'm') OR (sex == 'M')) AND (*this* == null)) OR (*this* != null))&lt;/test&gt;
+  &lt;/var&gt;
+&lt;/field&gt;
+</pre>
+     <p>Let's assume you have a medical information form with three fields, sex, pregnancyTest, and testResult.
+     If sex is 'f' or 'F', pregnancyTest is required.  If pregnancyTest is not blank, testResult is required.
+     The entry in your validation.xml file would look like this:
+     </p>
+     <pre>
+&lt;form name="medicalStatusForm"&gt;
+
+&lt;field
+    property="pregnancyTest" depends="requiredif"&gt;
+  &lt;arg0 key="medicalStatusForm.pregnancyTest.label"/&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;field[0]&lt;/var-name&gt;
+    &lt;var-value&gt;sex&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;fieldTest[0]&lt;/var-name&gt;
+    &lt;var-value&gt;EQUAL&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;fieldValue[0]&lt;/var-name&gt;
+    &lt;var-value&gt;F&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;field[1]&lt;/var-name&gt;
+    &lt;var-value&gt;sex&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;fieldTest[1]&lt;/var-name&gt;
+    &lt;var-value&gt;EQUAL&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;fieldValue[1]&lt;/var-name&gt;
+    &lt;var-value&gt;f&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;fieldJoin&lt;/var-name&gt;
+    &lt;var-value&gt;OR&lt;/var-value&gt;
+  &lt;/var&gt;
+&lt;/field&gt;
+
+&lt;field
+    property="testResult" depends="requiredif"&gt;
+  &lt;arg0 key="medicalStatusForm.testResult.label"/&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;field[0]&lt;/var-name&gt;
+    &lt;var-value&gt;pregnancyTest&lt;/var-value&gt;
+  &lt;/var&gt;
+  &lt;var&gt;
+    &lt;var-name&gt;fieldTest[0]&lt;/var-name&gt;
+    &lt;var-value&gt;NOTNULL&lt;/var-value&gt;
+  &lt;/var&gt;
+&lt;/field&gt;
+&lt;/form&gt;
+</pre>
+</section>
+
+<section href="validate" name="When is the best time to validate input?">
+<p>
+This is an excellent question.  Let's step back a second and think about a
+typical mid to large size application.  If we start from the back end and work
+toward the view we have:
+</p>
+<p>
+1) Database:  Most modern databases are going to validate for required
+fields, duplicate records, security constraints, etc.</p>
+<p>
+2) Business Logic:  Here you are going to check for valid data relationships
+and things that make sense for the particular problem you are triing to
+solve.</p>
+<p>
+... This is where struts comes into the picture, by now the system should be
+pretty well bulletproof.  What we are going to do is make validation friendlier
+and informative.  Rember it is OK to have duplicate validations...</p>
+<p>
+3) <code>ActionErrors validate(ActionMapping map, HttpServletRequest req)</code>
+is where you can do your validation and feed back to the view,
+information required to correct any errors.  <code>validate</code> is run after
+the form has been <code>reset</code> and after the <code>ActionForm</code>
+properties have been set from corresponding view based input. Also remember you
+can turn validation off with <code>validate="false"</code> in the
+<code>action</code> mapping in the <code>struts-config.xml</code>. This is done
+by returning an <code>ActionErrors</code> collection with messages from your
+<code>ApplicationResources.properties</code> file.</p>
+<p>
+Here you have access to the request so you can see what kinds of action is
+being requested to fine tune your validations.  The &lt;html:error&gt; tag
+allows you to dump all errors on your page or a particular error associated
+with a particular property.  The <code>input</code> attribute of the
+<code>struts-config.xml</code> <code>action</code> allows you to send
+validation errors to a particular jsp / html / tile page.</p>
+<p>
+4) You can have the system perform low level validations and client side
+feedback using a <code>ValidatorForm</code> or its derivatives.  This will
+generate javascript and give instant feedback to the user for simple data entry
+errors.  You code your validations in the <code>validator-rules.xml</code>
+file.  A working knowledge of
+<a href="http://etext.lib.virginia.edu/helpsheets/regex.html">regular
+expressions</a> is necessary to use this feature effectively.  For more
+information, see
+<a href="../userGuide/dev_validator.html">
+User Guide</a></p>
+</section>
+
+<section href="avoidValidate"
+         name="How can I avoid validating a form before data is entered?">
+    <p>
+    The simplest way is to have two actions.  The first one has the job of setting
+    the form data, i.e. a blank registration screen.  The second action in our
+    writes the registration data to the database. Struts
+    would take care of invoking the validation and returning the user to the
+    correct screen if validation was not complete.
+    </p>
+
+    <p>
+    The EditRegistration action in the struts example application illustrates this:
+    </p>
+
+        <pre><code>
+    &lt;action path="/editRegistration"
+         type="org.apache.struts.webapp.example.EditRegistrationAction"
+         attribute="registrationForm"
+         scope="request"
+         validate="false"&gt;
+      &lt;forward name="success  path="/registration.jsp"/&gt;
+    &lt;/action&gt;
+        </code></pre>
+
+<p>
+When the /editRegistration action is invoked, a registrationForm is created and added to the request,
+but its validate method is not called. The default value of the <code>validate</code> attribute is
+<code>true</code>, so if you do not want an action to trigger form validation, you need to remember
+to add this attribute and set it to <code>false</code>.
+</p>
+
+</section>
+
+<section href="wizard" name="How can I create a wizard workflow?">
+    <p>
+        The basic idea is a series of actions with next, back, cancel
+        and finish actions with a common bean.  Using a LookupDispatchAction is
+        reccomended as it fits the design pattern well and can be internationalized
+        easily.  Since the bean is shared, each choice made will add data to the
+        wizards base of information.  A sample of struts-config.xml follows:
+    </p>
+
+    <pre><code>
+            &lt;form-beans&gt;
+                &lt;form-bean  name="MyWizard"
+                            type="forms.MyWizard" /&gt;
+            &lt;/form-beans&gt;
+
+        &lt;!-- the first screen of the wizard (next action only available) --&gt;
+        &lt;!-- no validation, since the finish action is not available --&gt;
+            &lt;actions&gt;
+                &lt;action path="/mywizard1"
+                        type="actions.MyWizard"
+                        name="MyWizard"
+                        validate="false"
+                        input="/WEB-INF/jsp/mywizard1.jsp"&gt;
+                    &lt;forward name="next"
+                        path="/WEB-INF/jsp/mywizard2.jsp" /&gt;
+                    &lt;forward name="cancel"
+                        path="/WEB-INF/jsp/mywizardcancel.jsp" /&gt;
+                &lt;/action&gt;
+
+                &lt;!-- the second screen of the wizard (back, next and finish) --&gt;
+                &lt;!-- since finish action is available, bean should validated, note
+        validation should not necessarily validate if back action requested, you
+        might delay validation or do conditional validation --&gt;
+                &lt;action path="/mywizard2"
+                        type="actions.MyWizard"
+                        name="MyWizard"
+                        validate="true"
+                        input="/WEB-INF/jsp/mywizard2.jsp"&gt;
+                    &lt;forward name="back"
+                        path="/WEB-INF/jsp/mywizard1.jsp" /&gt;
+                    &lt;forward name="next"
+                        path="/WEB-INF/jsp/mywizard3.jsp" /&gt;
+                    &lt;forward name="finish"
+                        path="/WEB-INF/jsp/mywizarddone.jsp" /&gt;
+                    &lt;forward name="cancel"
+                        path="/WEB-INF/jsp/mywizardcancel.jsp" /&gt;
+                &lt;/action&gt;
+
+                &lt;!-- the last screen of the wizard (back, finish and cancel only) --&gt;
+                &lt;action path="/mywizard3"
+                        type="actions.MyWizard"
+                        name="MyWizard"
+                        validate="true"
+                        input="/WEB-INF/jsp/mywizard3.jsp"&gt;
+                    &lt;forward name="back"
+                        path="/WEB-INF/jsp/mywizard2.jsp" /&gt;
+                    &lt;forward name="finish"
+                        path="/WEB-INF/jsp/mywizarddone.jsp" /&gt;
+                    &lt;forward name="cancel"
+                        path="/WEB-INF/jsp/mywizardcancel.jsp" /&gt;
+                &lt;/action&gt;
+    </code></pre>
+
+   <p>
+        The pieces of the wizard are as follows:
+    </p>
+
+    <p>
+        <strong>forms.MyWizard.java</strong> - the form bean holding the information required
+    </p>
+    <p>
+        <strong>actions.MyWizard.java</strong> - the actions of the wizard, note the use of
+        LookupDispatchAction allows for one action class with several methods.  All the
+        real work will be done in the 'finish' method.
+    </p>
+    <p>
+        <strong>mywizard[x].jsp</strong> - the data collection jsp's
+    </p>
+    <p>
+        <strong>mywizarddone.jsp</strong> - the 'success' page
+    </p>
+    <p>
+        <strong>mywizardcancel.jsp</strong> - the 'cancel' page
+    </p>
+
+</section>
+
+    <section href="chaining" name="How can I 'chain' Actions?">
+    <p>
+        Chaining actions can be done by simply using the proper mapping in your
+        forward entries in the struts-config.xml file. Assume you had the following
+        two classes:
+    </p>
+    <pre><code><![CDATA[
+    /* com/AAction.java */
+    ...
+
+    public class AAction extends Action
+    {
+        public ActionForward
+                execute(ActionMapping mapping,
+                        ActionForm form,
+                        HttpServletRequest request,
+                        HttpServletResponse response) throws
+                                                      Exception
+        {
+            // Do something
+
+            return mapping.findForward("success");
+        }
+    }
+    ]]></code></pre>
+    <pre><code><![CDATA[
+    /* com/BAction.java */
+    ...
+
+    public class BAction extends Action
+    {
+        public ActionForward
+                execute(ActionMapping mapping,
+                        ActionForm form,
+                        HttpServletRequest request,
+                        HttpServletResponse response) throws
+                                                      Exception
+        {
+            // Do something else
+
+            return mapping.findForward("success");
+        }
+    }
+    ]]></code></pre>
+
+       <p>
+       Then you can chain together these two actions with the Struts
+       configuration as shown in the following excerpt:
+       </p>
+
+    <pre><code><![CDATA[
+    ...
+    <action-mappings type="org.apache.struts.action.ActionMapping">
+       <action path="/A"
+               type="com.AAction"
+               validate="false">
+          <forward name="success" path="/B.do" />
+       </action>
+       <action path="/B"
+               type="com.BAction"
+               scope="session"
+               validate="false">
+          <forward name="success" path="/result.jsp" />
+       </action>
+    </action-mappings>
+    ...
+    ]]></code></pre>
+
+       <p>
+       Here we are assuming you are using a suffix-based (<code>.do</code>) servlet
+       mapping, which is recommended since module support requires it. When you
+       send your browser to the web application and name the action
+       <code>A.do</code> (i.e. <code>http://localhost:8080/app/A.do</code>) it will
+       execute <code>AAction.execute()</code>, which will then forward to the
+       "success" mapping.
+       </p>
+
+       <p>
+       This causes the execution of <code>BAction.execute()</code> since the
+       <code>&lt;forward&gt;</code> entry for "success" in the configuration file
+       uses the <code>.do</code> suffix.
+       </p>
+
+       <p>
+       Of course it is also possible to chain actions programmatically, but the
+       power and ease of being able to "reroute" your web application's structure
+       using the XML configuration file is much easier to maintain.
+       </p>
+
+        <p>
+    As a rule, chaining Actions is <strong>not</strong> recommended.
+    If your business classes are properly factored, you should be able to call
+    whatever methods you need from any Action, without splicing them together
+    into a cybernetic Rube Goldberg device.
+        </p>
+
+        <p>
+    If you must chain Actions, be aware of the following:
+    calling the second Action from the first Action has the same effect as calling the second
+    Action from scratch.
+    If both of your Actions change the properties of a formbean,
+    the changes made by the first Action will be lost because Struts calls the reset() method on
+    the formbean when the second Action is called.
+        </p>
+
+</section>
+
+<section
+    href="undocumented"
+    name="If you would like to contribute, here is a list of
+    popular but undocumented questions">
+
+    <ul>
+
+    <li>How can I capture binary or formatted values, like dates or telephone numbers?</li>
+
+    <li>Why do my option lists disappear when validation fails?</li>
+
+    <li>Why can't I disable URL-encoding in the Struts taglibs?</li>
+
+    <li>Can I create dynamic ActionForwards?</li>
+
+    <li>How can I use my own (ActionForm, ActionForward, ActionMapping, ActionServlet) class?</li>
+
+    </ul>
+
+</section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/faqs/project.xml b/build-legacy/core/xdocs/faqs/project.xml
new file mode 100644
index 0000000..414ec94
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/project.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+
+<project 
+    name="Apache Struts Web Application Framework"
+    href="http://jakarta.apache.org/struts"
+    image="images/struts.gif"
+    authors="false">
+
+    <title>Apache Struts Web Application Framework</title>
+
+    <menu name="FAQs">
+        <item 
+            href="kickstart.html" 
+            name="Kickstart"/>
+        <item 
+            href="newbie.html" 
+            name="Newbie"/>
+        <item 
+            href="helping.html" 
+            name="How to Help"/>
+    </menu>
+
+    <menu name="Howto Guides">
+        <item 
+            href="actionForm.html" 
+            name="Action Forms"/>
+        <item 
+            href="apps.html" 
+            name="Building Apps"/>
+        <item 
+            href="database.html" 
+            name="Database"/>
+        <item 
+            href="indexedprops.html" 
+            name="Indexed Properties"/>
+        <item 
+            href="ssl.html" 
+            name="SSL"/>
+
+        <item
+            href="struts-el.html"
+            name="Struts-EL (JSTL)"/>
+    </menu>
+
+    <menu name="IDE Guides">
+        <item 
+            href="eclipse.html" 
+            name="Eclipse"/>
+        <item 
+            href="netbeans.html" 
+            name="Netbeans"/>
+    </menu>
+
+    <menu name="Quick Links">
+        <item 
+            name="Welcome"                 
+            href="../index.html"/>
+
+        <item
+        	name="User and Developer Guides"
+            href="../userGuide/index.html"
+            />
+    </menu>
+
+</project>
+
+
+
+
+
+
diff --git a/build-legacy/core/xdocs/faqs/ssl.xml b/build-legacy/core/xdocs/faqs/ssl.xml
new file mode 100644
index 0000000..cd1fa55
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/ssl.xml
@@ -0,0 +1,138 @@
+<?xml version="1.0"?>
+
+<document url="./ssl.xml">
+
+<properties>
+
+
+<title>Secure Socket Layer and Web Applications - Apache Struts</title>
+
+</properties>
+
+<body>
+
+<section href="ssl" name="Secure Socket Layer and Web Applications"/>
+
+<section href="overview" name="Overview">
+
+<p>
+Many web applications, especially those deployed for e-commerce, necessitate the
+transmission of sensitive data between the web server and the client browser.  This data
+may include passwords, credit card numbers, bank account numbers or any other
+information that users would not want to divulge to the general public. To protect
+sensitive data during transmission, application developers typically use the Secure
+Sockets Layer (SSL) and its companion protocol, HTTP over Secure Sockets Layer
+(HTTPS). HTTPS employs SSL to protect data by encrypting it at the source, be it the
+server or the client, and decrypting it at the destination. This prevents anyone monitoring
+Internet data transmissions from easily capturing this data. The client and server
+exchange public keys to enable encryption and decryption to occur.
+</p>
+
+<p>
+The encryption/decryption process comes at a performance price, however. The
+throughput of data for a web server transmitting via HTTPS is often as little as one-tenth
+that of data transmission via HTTP. For this reason, it is undesirable to deploy an entire
+web application under SSL. For fastest performance, it is best to deploy a web
+application under HTTP and employ HTTPS only for those pages and processes that
+transmit sensitive data.
+</p>
+
+</section>
+
+<section href="mixing" name="Mixing Protocols in Web Applications">
+
+<p>
+Switching back and forth between the two protocols can require hard-coding the protocol
+and full URL in every link to each resource in the web application. This creates an
+ongoing maintenance headache for developers each time a server name changes or secure
+protocol requirements change for resources in the web app.
+</p>
+
+<p>
+Another significant hazard is that there is nothing to prevent a user from specifying the
+wrong protocol by manually entering a URL into the browser. The penalty for manually
+specifying HTTPS for a page or servlet that does not require HTTPS is reduced
+performance. Far worse is the penalty for manually specifying HTTP for non-secure
+access of a page that does require HTTPS: public exposure of sensitive data.
+</p>
+
+</section>
+
+<section href="help" name="Help from Deployment Descriptor">
+
+<p>
+To help overcome the problem of non-secure access of sensitive data, the Java Servlet
+Specification (versions 2.2 and 2.3) defines the transport-guarantee element of the
+web.xml deployment descriptor file. The transport-guarantee element must specify one
+of three types of protection for communication between client and server: NONE,
+INTEGRAL, or CONFIDENTIAL. For most containers a specification of INTEGRAL
+or CONFIDENTIAL is treated as a requirement for SSL usage. Web application
+containers will prevent users from accessing web resources over HTTP if they have been
+so specified.
+</p>
+
+<p>
+The implementation for blocking HTTP access to web resources specified as INTEGRAL
+or CONFIDENTIAL varies from container to container. If a user attempts to access such
+a resource over HTTP, some containers will present that user with an error message
+instructing them to use the HTTPS protocol for accessing the requested resource. Other
+containers will actually redirect the request using the HTTPS protocol, but then continue
+using the HTTPS protocol for all subsequent requests, even those for resources with a
+transport-guarantee specification of NONE.
+</p>
+
+</section>
+
+<section href="sslext" name="The sslext Struts Extension">
+
+<p>
+An extension to Struts 1.1, named sslext, helps solve many of these issues for Struts
+developers. It extends the ActionConfig class, RequestProcessor, and Plugin classes to
+define a framework where developers may specify the transmission protocol behavior for
+Struts applications. Within the Struts configuration file, developers specify which action
+requests require HTTPS transmission and which should use HTTP. Developers can also
+specify whether to redirect "improperly-protocoled" requests to the correct protocol.
+</p>
+
+<p>
+In addition to these extensions, the &lt;html:link> and the &lt;html:form> tags have been
+extended. In these extensions, the Struts actions specified in either of these tags are
+analyzed to determine the protocol that should be used in requesting that action. The
+HTML generated by these tags will specify the proper protocol. An additional custom
+tag is defined for allowing users to specify the transmission protocol for an individual
+JSP. This is most often used for form-based authentication pages.
+</p>
+
+<p>
+The sslext library may be obtained from <a href="http://sslext.sourceforge.net">
+http://sslext.sourceforge.net</a>
+</p>
+
+</section>
+
+<section href="legacy" name="Legacy Browser Issue">
+
+<p>
+One additional complication faced by developers of web applications is that some
+browsers (e.g. pre-6.0 versions of Netscape Navigator) will treat requests to different
+protocols and ports on the same server as requests to different domains. This causes
+these browsers to initiate a new session each time a different protocol or port is specified
+in a request. This problem can only be solved at the container level. Some containers
+have a "session domain" or "cookie domain" configuration parameter to allow the session
+to be shared across different servers in the same domain. As an example, the Weblogic
+Server has a "CookieDomain" property configured in its weblogic.xml deployment
+descriptor. Thankfully, the effects of this problem are diminishing as people upgrade
+their browsers to the current versions.
+</p>
+
+</section>
+
+<section href="containers" name="Configuring Containers for SSL">
+
+The procedure for configuring SSL for a container will be specific to that container.  The
+procedure for enabling SSL for Tomcat can be found
+<a href="http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html">here</a>.
+
+</section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/faqs/struts-el.xml b/build-legacy/core/xdocs/faqs/struts-el.xml
new file mode 100644
index 0000000..759a801
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/struts-el.xml
@@ -0,0 +1,130 @@
+<?xml version="1.0"?>
+<document url="./struts-el.xml">
+<properties>
+<title>Struts EL Extension - Apache Struts</title>
+</properties>
+<body>
+<section href="faq" name="Struts EL Extension"/>
+
+    <section href="Introduction" name="Introduction">
+
+    <p>
+        This subproject is an extension of the Struts tag library.  Each JSP custom tag
+       in this library is a subclass of an associated tag in the Struts tag library.
+       One difference is that this tag library does not use "rtexprvalues", it uses
+       the expression evaluation engine in the Jakarta Taglibs implementation of the
+       JSP Standard Tag Library (version 1.0) to evaluate attribute values.
+    </p>
+
+    <p>
+       In addition, some of the Struts tags were not ported to this library, as it was
+       determined that their functionality was entirely supplied by the JSTL.  These
+       particular Struts tags, and the reason for their non-porting will be described
+       in the documentation for this library.
+    </p>
+
+    <p>
+       In order to fully understand the correct utilization of this library, you must
+       understand the use and operation of the Struts tag library, and the use and
+       operation of the JavaServer Pages Standard Tag Library (hereafter called the
+       "JSTL"), along with the expression language (sometimes called the "EL") used
+       for evaluating attribute values.
+    </p>
+
+    </section>
+
+       <section href="TagMapping" name="Tag Mapping">
+
+    <p>
+       In implementing the Struts-EL library, every Struts tag that provides a feature
+       that is not covered by the JSTL (1.0) library is mapped into the Struts-EL
+       library.  This section reviews which Struts tags are NOT implemented in the
+       Struts-EL library, and which JSTL tags provide that feature.
+    </p>
+
+    <p>
+       Many of the non-porting decisions were based on the fact that the JSTL
+       expression language itself provides the same functionality.  In those cases, in
+       addition to a possible JSTL tag name, the symbol "EL" will be listed.
+    </p>
+
+    <p>
+       <strong> Bean Tag Library Tags NOT Implemented in Struts-EL</strong>
+    </p>
+
+    <table>
+    <tr><th>Struts Tag</th><th>JSTL Tag</th></tr>
+    <tr><td>cookie</td><td>c:set, EL</td></tr>
+    <tr><td>define</td><td>c:set, EL</td></tr>
+    <tr><td>header</td><td>c:set, EL</td></tr>
+    <tr><td>include</td><td>c:import</td></tr>
+    <tr><td>parameter</td><td>c:set, EL</td></tr>
+    <tr><td>write</td><td> c:out</td></tr>
+    </table>
+
+    <p>
+       <strong>Bean Tag Library Tags NOT Implemented in Struts-EL</strong>
+    </p>
+
+    <table>
+    <tr><th>Struts Tag</th><th>JSTL Tag</th></tr>
+    <tr><td>empty</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>equal</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>greaterEqual</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>greaterThan</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>lessEqual</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>lessThan</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>notEmpty</td><td>c:if, c:when, EL</td></tr>
+    <tr><td>notEqual</td><td>c:if, c:when, EL</td></tr>
+    </table>
+
+    <p>
+       (Note that the "iterate" tag was originally ported, even with the presence of
+       the "c:forEach" tag, as the "indexed tag" functionality was not supported when
+       using "c:forEach" instead of "logic:iterate".  This has since been rectified,
+       such that the "indexed tag" functionality checks for being contained in a
+       "c:forEach" tag, in addition to the "logic:iterate" tag.  However, the ported
+       "iterate" tag has not been removed from Struts-EL, for backward compatibility.)
+    </p>
+
+    <p>
+       <strong>Html Tag Library Tags NOT Implemented in Struts-EL</strong>
+    </p>
+
+    <p>
+       None (all of them were ported).
+    </p>
+
+    </section>
+
+    <section href="AttributeMapping" name="Attribute Mapping">
+
+    <p>
+       At this point of the implementation, there is only one change (to two similar
+       tags) to the set of attributes between the Struts tags, and the Struts-EL tags.
+       The "logic:match" and "logic:notMatch" tags have an additional attribute named
+       "expr", which can take any value, and will be used as the value to compare
+       against, in addition to the choices of "cookie", "header", "name"/"property",
+       and "parameter".
+    </p>
+
+    </section>
+
+    <section href="UsageRequirements" name="Usage Requirements">
+
+    <p>
+       The Struts-EL tag library requires the use of the Struts tag library, and the
+       Java Server Pages Standard Tag Library.  It is not necessary for JSP pages
+       using the Struts-EL tag library to also use the Struts tags or the JSTL tags,
+       but the Struts and JSTL tag libraries need to be part of the application
+       utilizing the Struts-EL tag library.
+    </p>
+
+    <p>
+       This is because the Struts-EL tag classes are all subclasses of Struts tag
+       classes, and their implementation uses classes provided by the JSTL.
+    </p>
+
+    </section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/faqs/works.xml b/build-legacy/core/xdocs/faqs/works.xml
new file mode 100644
index 0000000..2bc69a9
--- /dev/null
+++ b/build-legacy/core/xdocs/faqs/works.xml
@@ -0,0 +1,177 @@
+<?xml version="1.0"?>
+<document url="./newbie.xml">
+<properties>
+<title>How Does Struts Work? - Apache Struts</title>
+</properties>
+<body>
+
+<section href="how" name="How does Struts work?">
+
+<p>
+    Java Servlets are designed to handle requests made by Web browsers.
+    Java ServerPages are designed to create dynamic Web pages that can turn billboard sites into live applications.
+    Struts uses a special Servlet as a switchboard to route requests from Web browsers to the appropriate ServerPage.
+    This makes Web applications much easier to design, create, and maintain.
+</p>
+
+<p>
+    Here is some more detail on the mechanisms and dependencies of Struts:
+</p>
+
+<ul>
+   <li>
+      The web application that you develop has a deployment descriptor
+      (<code>WEB-INF/web.xml</code>) which you must write. This file describes
+      the configuration of your web application, including welcome pages (the
+      file that is shown in a directory when none is specified by the request),
+      mappings to servlets (path or extension name), and parameters to those
+      servlets.<br/>
+
+      In this file, you configure the Struts
+      <a href="../api/org/apache/struts/action/ActionServlet.html"><code>ActionServlet</code></a>
+      as the servlet that will handle all requests for a given mapping (usually
+      the extension <code>.do</code>). This is the "switchboard" mentioned
+      above.<br/>
+
+      In this same file, you configure the <code>ActionServlet</code> to use
+      one or more configuration files for Struts itself.<br/>
+      For this text, assume we are installing the web application on the server
+      at <code>/myapp</code>, and are using the simplest possible configuration
+      from there.<br/>
+
+      If you need more details on deployment descriptors, read
+      the Servlet Specification available from Sun Microsystem's
+      <a href="http://java.sun.com">Java site</a>.<br/>
+   </li>
+   <li>
+      In the Struts configuration file(s), you associate paths with
+      the controller components of your application, known as
+      <a href="../api/org/apache/struts/action/Action.html"><code>Action</code></a>
+      classes (i.e. "login" ==&gt; LoginAction class). This tells the Struts
+      <code>ActionServlet</code> that when the incoming request is
+      <code>http://myhost/myapp/login.do</code> it should invoke your
+      controller component <code>LoginAction</code>.<br/>
+
+      Note the extension <code>.do</code> in this URL. The extension causes
+      your container (i.e.  Tomcat) to call the <code>ActionServlet</code>,
+      which sees the word "login" as the thing you want to do. The
+      configuration is referenced, and your <code>LoginAction</code> is
+      executed.<br/>
+   </li>
+   <li>
+      For each <code>Action</code>, you also configure Struts with the names of
+      the resulting page(s) that can be shown as a result of that action. There
+      can be more than one view as the result of an action (often, there are at
+      least two: one for success, and one for failure).<br/>
+
+      Your <code>Action</code> (the controller component you write) is based on
+      these <em>logical</em> result mapping names. It reports back to the
+      <code>ActionServlet</code> using words like "success", "failure",
+      "ready", "ok", "UserIsIncompetent", etc.  The Struts system (through the
+      configuration that you wrote) knows how to forward to the proper
+      <em>specific</em> page. This has the added advantage of reconfiguration of
+      the view layer by simply editing the Struts XML configuration file.<br/>
+
+      At this point Struts knows how to delegate to your controller components,
+      and what to show as a result of your controller processing. The "model"
+      part of the application is completely up to you, and is called from
+      within your controller components.
+   </li>
+   <li>
+      You may also associate a Java Bean with an action (or set of actions) in
+      the Struts configuration file. The Java Bean is used as a repository for
+      form or display data that can be communicated between the view and
+      controller layer.<br/>
+
+      These Beans are automatically made visible to your controller components
+      (like <code>LoginAction</code>) and any view page that is associated with
+      that controller. <br/>
+
+      These Beans can also be validated with the help of the Struts system to
+      help insure that the user is putting good data in the form. They can be
+      carried along with a session, allowing forms to span multiple pages of
+      the view, and Actions in the controller.<br/>
+
+      <strong>Note</strong>: You must be using some sort of server-side
+      technology (JSP, Velocity, XSLT) for the view layer (going <em>to</em> the
+      client) to see this data (plain HTML won't work). Struts works on the
+      server side, so the client's view has to be composed there.<br/>
+
+      The client feeds the data back through normal form submission (POST/GET)
+      methods, and the Struts system updates that data in the Bean before
+      calling your controller components.
+   </li>
+   <li>
+      Within your web application will be pages that represent the view your
+      users will see. These can be JSP pages, Velocity Templates,
+      XSLT pages, and so forth.
+      A set of JSP tags is bunded with the Struts distribution so that you
+      can get started right away, but any standard presentation technology
+      can be used with Struts.<br/>
+
+      Even plain HTML files can be used within your Struts application,
+      although they will not take full advantage of all of the dynamic
+      features.<br/>
+
+      Following the example of the Struts JSP taglibs, several other
+      packages are available to make the framework easy to use with your
+      favorite presentation technology.
+      For Velocity templates, there are the
+      <a href="http://jakarta.apache.org/velocity/">Velocity</a> ViewTools
+      for Struts.
+      If you want to use XSLT in you application, you can choose between
+      <a href="http://www.openroad.ca/opencode/">stxx</a> and
+      <a href="http://it.cappuccinonet.com/strutscx/">
+      StrutsCX</a>.<br/>
+
+      These packages make the standard Struts framework elements look and
+      feel like a seamless part of the original presentation technology.
+      Struts also makes it easy to mix and match.
+      If need be, you can use JSP, Velocity templates, and XSLT all in
+      the same application!<br/>
+
+      Since Struts relies on standard Servlet technologies, you should be
+      able to use any Java presentation technology with Struts.
+   </li>
+   <li>
+      While the focus of the Struts framework is on the controller,
+      the presentation layer is a significant part of any application.
+      The Struts JSP taglibs include a number of generic and Struts-specific
+      tags to help you use dynamic data in your view. <br/>
+
+      The custom JSP tags account for a good deal of the Struts code base. It
+      is educational to note that as of version 1.1b3 the Java code for the
+      core of Struts was about 28,000 lines, and the Java code for the tag
+      libraries (including tiles) was about 41,000 lines.<br/>
+
+      These tags help you glue your view layer to the controller layer without
+      having to embed a lot of Java in the JSP. This gives the page an XML
+      look, and can be easier for web designers to deal with than a plain JSP. It
+      also helps minimize dependencies between the controller and view.<br/>
+
+      The custom tags are used to create forms (and invisibly interact with the
+      Bean mentioned previously), logically forward to other pages, and invoke
+      other actions of the web application.<br/>
+
+      There are also tags that help you with internationalization, error
+      messages, etc.<br/>
+
+      All of these abilities depend in some way on the configuration files you
+      supplied to Struts.
+   </li>
+</ul>
+<p>
+   It is important for you to remember that the mechanism described here is
+   only in effect when the <code>ActionServlet</code> is handling the
+   request.
+</p>
+<p>
+   Since this only happens when a request is submitted that causes your
+   container (i.e. Tomcat, WebSphere, etc.) to call <code>ActionServlet</code>,
+   you must be sure that any page that relies on Struts is done through a
+   request that will map to the <code>ActionServlet</code> (i.e. has a
+   <code>.do</code> extension).
+</p>
+ </section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/images/logos/struts-power.gif b/build-legacy/core/xdocs/images/logos/struts-power.gif
new file mode 100644
index 0000000..5f4e9d4
--- /dev/null
+++ b/build-legacy/core/xdocs/images/logos/struts-power.gif
Binary files differ
diff --git a/build-legacy/core/xdocs/images/struts-blue-1.gif b/build-legacy/core/xdocs/images/struts-blue-1.gif
new file mode 100644
index 0000000..ad32937
--- /dev/null
+++ b/build-legacy/core/xdocs/images/struts-blue-1.gif
Binary files differ
diff --git a/build-legacy/core/xdocs/images/struts-blue-2.gif b/build-legacy/core/xdocs/images/struts-blue-2.gif
new file mode 100644
index 0000000..17fc396
--- /dev/null
+++ b/build-legacy/core/xdocs/images/struts-blue-2.gif
Binary files differ
diff --git a/build-legacy/core/xdocs/images/struts-blue-3.gif b/build-legacy/core/xdocs/images/struts-blue-3.gif
new file mode 100644
index 0000000..7ebba3a
--- /dev/null
+++ b/build-legacy/core/xdocs/images/struts-blue-3.gif
Binary files differ
diff --git a/build-legacy/core/xdocs/images/struts-blue.gif b/build-legacy/core/xdocs/images/struts-blue.gif
new file mode 100644
index 0000000..dfb92f2
--- /dev/null
+++ b/build-legacy/core/xdocs/images/struts-blue.gif
Binary files differ
diff --git a/build-legacy/core/xdocs/index.xml b/build-legacy/core/xdocs/index.xml
new file mode 100644
index 0000000..9c490bb
--- /dev/null
+++ b/build-legacy/core/xdocs/index.xml
@@ -0,0 +1,193 @@
+<?xml version="1.0"?>
+<document>
+
+<properties>
+    <title>The Apache Struts Web Application Framework</title>
+</properties>
+
+<body>
+    
+    <section name="Welcome to Struts" href="Welcome">
+
+    <p>
+    Welcome to Struts!
+    The goal of this project is to provide an open source framework for 
+    building Java web applications.
+    </p>
+
+    <p>
+    The core of the Struts framework is a flexible control layer based on
+    <a href="userGuide/preface.html">standard technologies</a> like Java 
+    Servlets, JavaBeans, ResourceBundles, and XML, as well as various
+    <a href="http://jakarta.apache.org/commons/index.html">Jakarta Commons</a> packages.
+    Struts encourages application architectures based on the Model 2 approach,
+    a variation of the classic
+    <a href="http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html">
+    <strong>Model-View-Controller</strong></a> (MVC) design paradigm.
+    </p>
+
+    <p>
+        Struts provides its own <strong>Controller</strong> component and integrates with <a href="userGuide/preface.html#layers">
+        other technologies</a> to provide the Model and the View.
+
+        For the <strong>Model</strong>, Struts can interact with standard data access
+        technologies, like <a href="http://java.sun.com/products/jdbc/">JDBC</a> and
+        <a href="http://java.sun.com/products/ejb/">EJB</a>, as well as most any third-party packages, like
+        Hibernate, iBATIS, or Object Relational Bridge.
+
+        For the <strong>View</strong>, Struts works well with 
+        <a href="http://java.sun.com/products/jsp/">JavaServer Pages</a>, including
+        <a href="./faqs/kickstart.html#jsf">JSTL and JSF</a>, as well as Velocity Templates, XSLT, and
+        other presentation systems.
+    </p>
+
+    <p>
+    The Struts framework provides the invisible underpinnings every 
+    professional web application needs to survive.
+    Struts helps you create an extensible development environment for your 
+    application, based on published standards and proven design patterns.
+    </p>
+
+    <p>
+    Struts is part of the
+    <a href="http://jakarta.apache.org">Apache Jakarta Project</a>,
+    sponsored by the
+    <a href="http://www.apache.org">Apache Software Foundation</a>.
+    The official Struts home page is at
+    <a href="http://jakarta.apache.org/struts">
+    http://jakarta.apache.org/struts</a>.
+    </p>
+
+    <p>
+        Struts is a volunteer project and all support for the framework is provided by unpaid volunteers.
+        This documentation bundle and the mailing lists are the primary ways to learn how to use Struts.
+        The next few pages are devoted to helping you understand what resources are available to you.
+        Since Struts is a volunteer project, and our resources are limited, it is important that we first help you
+        help yourself.
+    </p>
+
+    </section>
+
+    <section name="Struts in a Nutshell" href="nutshell">
+
+        <p>
+            A <a href="http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebApp.html">web application</a> uses a
+            deployment descriptor to initialize resources like <a href="userGuide/preface.html#servlets">servlets</a>
+            and <a href="userGuide/preface.html#jsp">taglibs</a>.
+            The deployment descriptor is formatted as a <a href="userGuide/preface.html#xml">XML</a> document and named
+            "web.xml".
+            Likewise, Struts uses a configuration file to initialize its own resources.
+            These resources include <a href="userGuide/building_controller.html#action_form_classes">ActionForms</a> to
+            collect input from users,
+            <a href="http://jakarta.apache.org/struts/userGuide/building_controller.html#actionmapping">
+            ActionMappings</a> to direct input to server-side
+            <a href="http://jakarta.apache.org/struts/userGuide/building_controller.html#action_classes">Actions</a>,
+            and ActionForwards to select output pages.
+        </p>
+
+        <p>
+            Here's a simple Struts configuration (struts-config.xml) for a login workflow:
+        </p>
+
+    <source><![CDATA[
+    <?xml version="1.0" encoding="ISO-8859-1" ?>
+    <!DOCTYPE struts-config PUBLIC
+              "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
+              "http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd">
+    <struts-config>
+        <form-beans>
+            <form-bean
+                name="logonForm"
+                type="app.LogonForm"/>
+        </form-beans>
+        <action-mappings>
+            <action
+                path="/Welcome"
+                forward="/pages/Welcome.jsp"/>
+            <action
+                path="/Logon"
+                forward="/pages/Logon.jsp"/>
+            <action
+                path="/LogonSubmit"
+                type="app.LogonAction"
+                name="logonForm"
+                scope="request"
+                validate="true"
+                input="/Logon.do">
+                <forward
+                    name="success"
+                    path="/Welcome.do"/>
+                <forward
+                    name="failure"
+                    path="/Logon.do"/>
+            </action>
+            <action
+                path="/Logoff"
+                type="app.LogoffAction">
+                <forward
+                    name="success"
+                    path="/Welcome.do"/>
+            </action>
+        </action-mappings>
+        <message-resources parameter="resources.application"/>
+    </struts-config>
+    ]]></source>
+
+        <p>
+            There are several other resources you can specify in Struts configuration files.
+            You can specify validations for the ActionForms in an XML descriptor, using the
+            <a href="userGuide/dev_validator.html">Struts Validator</a>.
+            Another extension, <a href="userGuide/dev_tiles.html">Tiles</a>, helps you build pages from smaller
+            fragments.
+        </p>
+
+        <p>
+            Struts is an extensible framework.
+            Every class deployed by Struts can be replaced by your own default class.
+            The properties of your default class can be set using the
+            <a href="http://jakarta.apache.org/commons/digester/"> Digester's</a> <code>set-property</code> feature.
+            This is one reason why there are so many <a href="resources/extensions.html">contributor extensions</a> for
+            Struts.
+            Struts provides a base framework, but you can still write <b>your</b> application <b>your</b> way.
+        </p>
+
+        <p>
+            For more about Struts and its underlying technologies, see the <a href="userGuide/index.html">User
+            Guide</a> and the Developer Guides.
+        </p>
+
+    </section>
+
+    <section name="Is Struts the best choice for every project?">
+
+        <p>
+            No. If you need to write a very simple application, with a handful of pages,
+            then you might consider a "Model 1" solution that uses only server pages.
+        </p>
+
+        <p>
+            But, if you are writing a more complicated application, with dozens of pages,
+            that need to be maintained over time, then Struts can help. For more about
+            whether Model 1 or or MVC/Model 2 is right for you, see
+            <a href="http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html">Understanding JavaServer
+            Pages Model 2 architecture</a> and
+            <a href="http://www.scioworks.net/devnews/articles/struts_adoption_issues/index.html">
+            Issues in Struts Adoption</a>.
+        </p>
+
+    </section>
+
+    <section>
+        <p>
+        Next: <a href="learning.html">Learning About Struts</a>
+        </p>
+    </section>
+
+    <section>
+        <p>
+        <a href="faqs/kickstart.html#jsf">What about JSTL and JavaServer Faces?</a>
+        </p>
+    </section>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/learning.xml b/build-legacy/core/xdocs/learning.xml
new file mode 100644
index 0000000..8129288
--- /dev/null
+++ b/build-legacy/core/xdocs/learning.xml
@@ -0,0 +1,292 @@
+<?xml version="1.0"?>
+<document url="./learning.xml">
+
+<!--
+// ======================================================================== 78
+-->
+
+<properties>
+    <title>Learning - The Apache Struts Web Application Framework</title>
+</properties>
+
+<body>
+<section name="Learning About Struts" href="Docs">
+
+    <p>
+    The <strong>official documentation</strong> for the framework is provided both 
+    online and as a self-installing WAR in the distribution. 
+    The <code>struts-documentation.war</code> includes our 
+    </p>
+
+    <ul>
+    <li>
+    <a href="userGuide/index.html">User and Developer Guides</a>,
+    </li>
+    <li>
+    <a href="api/index.html">Comprehensive Javadocs</a>,
+    </li>
+    <li>
+    <a href="./faqs/index.html">FAQ and Howto Guides</a>,
+    </li>
+    <li>
+    and everything else you find here.
+    </li>
+    </ul>
+
+    <p>
+    You are invited to preview the documentation online and then install 
+    the application locally for closer study.
+    </p>
+
+    
+    <strong>NOTE:</strong> If you are previewing the documentation on the website, 
+    most of the links in this section will refer to the <strong>Nightly Build</strong>.
+    When learning about Struts, <strong>be sure to refer to the documentation for 
+    the version you are actually using</strong>. 
+    The documentation is bundled with each distribution as an application that 
+    you can install and use locally.
+    
+
+    <p>
+    The concise Struts <a href="userGuide/index.html"><strong>User Guide</strong></a> 
+    introduces the Model-View-Controller architecture, and how it relates to 
+    the major components of Struts.
+    If you want to find out "How Struts works", this is the place to start.
+    Along with an architectural overview, the User Guide also includes 
+    detailed installation instructions and release notes for each version of 
+    the framework.
+    </p>
+
+    <p>
+        Our <strong>Developer Guides</strong> are detailed technical references to the extensions and components provided in the
+        Struts distribution.
+        Included are package overviews and API reference for each of the Struts taglibs, along with guides to the
+        Struts Utilities and the Struts Validator.
+        The Developer Guides are designed as a day-to-day reference to help you get the most out of the standard
+        packages.
+        Links to the various Developer Guides are provided as part of
+        <a href="userGuide/index.html"><strong>User Guide</strong></a> menu.
+    </p>
+
+    <p>
+    For more detail about a specific class or package, the Struts 
+    <a href="api/index.html"><strong>Javadocs</strong></a> are <strong>surprisingly 
+    comprehensive and carefully maintained</strong>. 
+    It is <em>strongly</em> recommended that you refer to the 
+    <a href="api/index.html"> Javadoc</a> for each class as you begin to use 
+    it. 
+    This will help ensure that important features and options are not 
+    overlooked. 
+    <em>What you don't know, can't help you.</em>
+    </p>
+
+    <p id="faqs">
+    The Struts <strong>FAQs</strong> are designed to fill in any small gaps left by the 
+    Javadocs or the User and Developer Guides. 
+    </p>
+
+    <ul>
+    <li>The <a href="./faqs/kickstart.html">Kickstart FAQ</a> 
+    answers the most common non-technical questions people first ask about 
+    Struts. 
+    </li>
+    <li>
+    The <a href="./faqs/newbie.html">Struts Newbie FAQ</a> answers the most 
+    common technical questions asked by first-timer Struts developers. 
+    </li>
+    <li>
+    The <a href="./faqs/helping.html">How to Help FAQ</a> answers the most 
+    common questions about contributing to the Jakarta-Struts project. 
+    </li>
+    </ul>
+
+    <p id="howtos">
+    The <strong>Howto Guides</strong> are designed to help you get started with some of 
+    the optional extensions and components available for Struts. 
+    These include topics like using the Secure Socket Layer (SSL) protocol 
+    with Struts and how to unit test your Struts applications. 
+    </p>
+
+    <p>
+        The <a href="http://wiki.apache.org/struts"><strong>Struts Wiki</strong></a> is a
+        relatively new addition to the Struts documentation.
+        All members of the Struts Community are invited to post comments to the Wiki, as well as the User List.
+        The Wiki is best suited for threads that you think are of lasting importance, while the mailing lists are best
+        suited for incidental questions.
+    </p>
+
+    <p>
+        If you have any comments on the pages you see here, they can be posted to the Wiki by following the link on the
+        bottom of any page.
+    </p>
+
+    <p>
+        For more help, you might try the JGuru Struts knowledgebase at the <a href="http://jguru.com/faq/Struts">JGuru
+        FAQ</a> and <a href="http://jguru.com/forums/Struts">Forum</a>.
+
+    </p>
+    <p>
+    Of course, the only true documentation is the code itself. 
+    If you have any questions about how Struts actually works, do not hesitate 
+    to <em>use the source</em>. 
+    For the complete, buildable source code to the entire Struts framework, 
+    see the "src" folder in
+    <a href="http://jakarta.apache.org/site/sourceindex.html"><strong>your source 
+    distribution</strong></a>.
+    </p>
+
+</section>
+
+<section name="Struts by Example" href="Examples">
+
+    <p>
+        To help you see how it all fits together, several example applications are bundled with the Struts
+        distribution:
+    </p>
+
+    <ul>
+        <li>
+            Blank - A simple template for starting new Struts applications.</li>
+        <li>
+            Exercise-Taglib - A set of test pages that also demonstrate use of the custom tags.</li>
+        <li>
+            Documentation - The Struts documentation bundle, as seen on the website.</li>
+        <li>
+            <strong>MailReader</strong> - The original Struts example application. <em>Try me first!</em></li>
+        <li>
+            Tiles-Doc - Extensive demonstration of Tiles extension.</li>
+        <li>
+            Upload - Demonstrates using the file upload facilities. (Based on Commons Upload.)</li>
+        <li>
+            Validator - Demonstrates using the Validator extension.</li>
+    </ul>
+
+    <p>
+        These applications are provided as standalone WARs in the binary distribution.
+        The source code for each application is available under <code>WEB-INF/src</code> in the binaries and under the
+        <code>web</code> package in the source distribution.
+    </p>
+
+    <p>
+        There are also many third-party example applications available for study, including these:
+    </p>
+
+    <ul>
+        <li>
+            <a href="http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse">AppFuse</a> - Demonstrates using XDoclet with
+            Struts, along with different security packages and Hibernate for database persistence.
+        </li>
+        <li>
+            <a href="http://www.ibatis.com/jpetstore/jpetstore.html">JPetStore</a> - A streamlined version of the Java
+            Petstore application implemented with Struts and iBATIS database layer.
+        </li>
+        <li>
+           <a href="http://www.codeczar.com/products/logweb/index.html">LogWeb</a> - A Struts webapp for configuring
+            Log4J at runtime within a servlet container.
+        </li>
+    </ul>
+
+</section>
+
+<section name="Learning More About Struts" href="More">
+    <p>
+    The Struts <a href="using.html#Lists">Mailing Lists</a> are a treasure trove of 
+    useful, interactive information. The user list tends to carry a high 
+    volume, so always check the published documentation and the
+    <a href="http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=42">
+    <strong>MAILING LIST ARCHIVE</strong></a> before 
+    <a href="http://www.catb.org/~esr/faqs/smart-questions.html">posting a
+    new question</a>.
+    Like as not, it's already been asked and answered.
+    </p>
+
+    <p>
+    If you really can't find the answer to your question in the 
+    <a href="#faqs">FAQs</a> or
+    <a href="http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=42">
+    list archive</a>, you can post your query to the Struts User list -- 
+    <strong>BUT YOU MUST SUBSCRIBE TO THE 
+    <a href="mailto:struts-user-subscribe@jakarta.apache.org">USER LIST</a>
+    OR THE <a href="mailto:struts-user-digest-subscribe@jakarta.apache.org">
+    USER LIST DIGEST</a> BEFORE POSTING</strong>. </p>
+
+    <p>
+        Please note that the Struts User list enjoys a "casual friday" policy. 
+        More off-topic  messages are tolerated on Fridays so long as the 
+        message is prefixed with the token [FRIDAY]. 
+        If you'd rather not be troubled by these postings, please set your 
+        mail filter accordingly. 
+        Posting [FRIDAY] articles on any other weekday is <strong>strongly 
+        discouraged</strong>. 
+        We thank you for your cooperation.
+    </p>
+
+    <p>
+        The Struts <a href="http://wiki.apache.org/struts"><strong>Wiki</strong></a> is a relatively
+        new addition to our documentation.
+        Any member of the community (that means you!) is invited to post new material to the Wiki.
+        However, the Wiki is not the place to ask incidental questions.
+        <strong>All support questions should be directed to the <a href="using.html#Lists">Struts User list</a> or
+        other support forum</strong>.
+    </p>
+
+    <p>
+        There is also a set of Wiki pages devoted to comments on the documentation.
+        To comment on the documentation, follow the "Comments?" link at the bottom of any page.
+    </p>
+
+    <p>
+    The <a href="status.html#roadmap"><strong>Roadmap</strong></a> page outlines our tentative plans for future development.
+    </p>
+
+</section>
+
+    <section name="Struts Community Resources" href="resources">
+
+    <p>
+        Struts has attracted a large and robust community of developers.
+        Some of these developers have a created an independant SourceForge site to promote new extensions to the Struts framework.
+        As a service to our community, the Struts SourceForge site maintains an
+        <a href="http://struts.sf.net/community/index.html">extensive directory of Struts resources</a>. including.
+    </p>
+
+    <ul>
+        <li>
+            <a href="http://struts.sf.net/community/articles.html">articles</a>,
+        </li>
+
+    <li>
+        <a href="http://struts.sf.net/community/books.html">books</a>,
+    </li>
+
+        <li>
+            <a href="http://struts.sf.net/community/examples.html">sample applications</a>,
+        </li>
+
+        <li>
+            <a href="http://struts.sf.net/community/tutorials.html">tutorials</a>, and more!
+        </li>
+
+    </ul>
+
+</section>
+
+    <section name="Books about Struts" href="books">
+
+       <p>
+       The Apache Software Foundation does not provide printed manuals,
+       but several third-party books about Struts are available.
+       A current list of books about Struts is maintained by the
+       <a href="http://struts.sf.net/community/index.html">Struts Community Resources area</a>.
+       </p>
+
+    </section>
+
+    <section>
+        <p class="right">
+        Next: <a href="acquiring.html">Acquiring Struts</a>
+        </p>
+    </section>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/navigation.xml b/build-legacy/core/xdocs/navigation.xml
new file mode 100644
index 0000000..475bf4a
--- /dev/null
+++ b/build-legacy/core/xdocs/navigation.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<project name="Struts">
+
+  <title>Struts</title>
+  <organizationLogo href="http://jakarta.apache.org/images/jakarta-logo-blue.gif">Jakarta</organizationLogo>
+
+  <body>
+  
+    <menu name="Struts">
+      <item name="Welcome"                    href="index.html"/>
+      <item name="Learning"                   href="learning.html"/>
+      <item name="Acquiring"                  href="acquiring.html"/>
+      <item name="Using"                      href="using.html"/>
+      <item name="Who We Are"                 href="volunteers.html"/>
+      <item name="Announcements"              href="announce.html"/>  
+    </menu>
+  
+    <menu name="Documentation">
+      <item name="User and Developer Guides"  href="userGuide/index.html"/>
+      <item name="Javadoc"                    href="apidocs/index.html"/>
+      <item name="FAQs and Howtos"            href="faqs/index.html"/>
+    </menu>
+    
+    <menu name="User Guide">
+      <item name="Table of Contents"          href="userGuide/index.html"/>
+      <item name="Preface"                    href="userGuide/preface.html"/>
+      <item name="Introduction"               href="userGuide/introduction.html"/>
+      <item name="Model Components"           href="userGuide/building_model.html"/>
+      <item name="View Components"            href="userGuide/building_view.html"/>
+      <item name="Controller Components"      href="userGuide/building_controller.html"/>
+      <item name="Configuration"              href="userGuide/configuration.html"/>
+      <item name="Release Notes"              href="userGuide/release-notes.html"/>
+      <item name="Installation"               href="userGuide/installation.html"/>
+    </menu>
+
+    <menu name="Developer Guides">
+      <item name="Bean Tags"                  href="userGuide/dev_bean.html"/>
+      <item name="HTML Tags"                  href="userGuide/dev_html.html"/>
+      <item name="Logic Tags"                 href="userGuide/dev_logic.html"/>
+      <item name="Nested Tags"                href="userGuide/dev_nested.html"/>
+      <item name="Tiles Tags"                 href="userGuide/dev_tiles.html"/>
+      <item name="Utilities"                  href="userGuide/dev_util.html"/>
+      <item name="Validator"                  href="userGuide/dev_validator.html"/>
+    </menu>    
+  
+    <menu name="Community">
+      <item name="Known Issues (Bugzilla)"    href="http://jakarta.apache.org/site/bugs.html"/>
+      <item name="Wiki Pages"                 href="http://wiki.apache.org/struts"/>
+      <item name="List Archive"               href="http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=42"/>
+      <item name="Resource Directory"         href="http://struts.sf.net/community/index.html"/>
+    </menu>
+
+    <menu name="Download">
+      <item name="Binaries"                   href="http://jakarta.apache.org/site/binindex.cgi"/>
+      <item name="Source Code"                href="http://jakarta.apache.org/site/sourceindex.cgi"/>
+    </menu>
+
+    <menu name="Development">
+    <!-- cvs-usage.html doesn't exist so I'm commenting this out
+      <item name="CVS Access"          href="cvs-usage.html"/>
+    -->  
+      <item name="Subversion Repository"             href="http://svn.apache.org/repos/asf/struts/core/trunk/"/>
+    <!-- Is there a Subversion equivalent? 
+      <item name="Subversion Changelog"              href="changelog-report.html"/>
+    -->  
+      <item name="File Activity"              href="file-activity-report.html"/>
+      <item name="Build Dependencies"         href="dependencies.html"/>
+      <item name="Release Guidelines"         href="releases.html"/>
+      <item name="Roadmap"                    href="status.html"/>
+    </menu>  
+  
+<!--  
+    <menu name="Struts">
+      <item name="Overview"                href="/index.html"/>
+      <item name="Community"               href="/community.html"/>
+      <item name="To Do List"              href="/tasks.html"/>
+      <item name="Resources"               href="/resources.html"/>
+      <item name="Legacy" href="/index.html" collapse="true">   
+	      <item name="Api 1.0" href="/api-1.0/org/apache/struts/package-summary.html" collapse="true"/>
+	      <item name="Api 1.1" href="/api-1.1/org/apache/struts/package-summary.html" collapse="true"/>
+	  </item>
+    </menu>
+-->
+    
+  </body>
+</project>
diff --git a/build-legacy/core/xdocs/project.xml b/build-legacy/core/xdocs/project.xml
new file mode 100644
index 0000000..3a0c6bd
--- /dev/null
+++ b/build-legacy/core/xdocs/project.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<project 
+    name="Struts Framework"
+        href="http://jakarta.apache.org/struts"
+       image="images/struts.gif">
+
+    <title>
+        Apache Struts Web Application Framework
+    </title>
+
+    <menu name="Struts">
+        <item 
+            name="Welcome"
+            href="index.html"
+            />
+        <item 
+            name="Learning"                
+            href="learning.html"
+            />
+        <item 
+            name="Acquiring"               
+            href="acquiring.html"
+            />
+        <item 
+            name="Using"                   
+            href="using.html"
+            />
+        <item
+            name="Who We Are"
+            href="volunteers.html"
+            />
+        <item
+            name="Announcements"
+            href="announce.html"
+            />
+</menu>
+
+    <menu name="Documentation">
+        <item
+            name="User and Developer Guides"
+            href="userGuide/index.html"
+            />
+        <item
+            name="Javadoc"
+            href="api/index.html"
+            />
+        <item
+            name="FAQs and Howtos"
+            href="faqs/index.html"
+            />
+    </menu>
+
+    <menu name="Community">
+        <item
+            name="Known Issues (Bugzilla)"
+            href="http://jakarta.apache.org/site/bugs.html"
+            />
+        <item
+            name="Wiki Pages"
+            href="http://wiki.apache.org/struts"
+            />
+        <item
+            name="List Archive"            
+            href="http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=42"
+            />
+        <item
+            name="Resource Directory"
+            href="http://struts.sf.net/community/index.html"
+            />
+    </menu>
+
+    <menu name="Download">
+        <item 
+            name="Binaries"                
+            href="http://jakarta.apache.org/site/binindex.cgi"
+            />
+        <item 
+            name="Source Code"             
+            href="http://jakarta.apache.org/site/sourceindex.cgi"
+            />
+    </menu>
+
+    <menu name="Development">
+        <!-- Not sure what would go here for Subversion
+        <item name="CVS Access"  href="reports/cvs-usage.html"/>
+        -->
+        <item
+            name="Subversion Repository"
+            href="http://svn.apache.org/viewcvs.cgi/struts/core/trunk/?root=Apache-SVN/"
+            />
+        <!-- Again, is there a Subversion equivalent?     
+        <item name="CVS Changelog"  href="reports/changelog-report.html"/>
+        -->
+        <item name="File Activity"  href="reports/file-activity-report.html"/>
+        <item name="Build Dependencies"  href="reports/dependencies.html"/>
+        <item
+            name="Release Guidelines"
+            href="releases.html"
+            />
+        <item
+            name="Roadmap"
+            href="status.html"
+            />
+    </menu>
+
+</project>
diff --git a/build-legacy/core/xdocs/proposals/project.xml b/build-legacy/core/xdocs/proposals/project.xml
new file mode 100644
index 0000000..cacbf28
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/project.xml
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<project name="Struts Framework"
+         href="http://jakarta.apache.org/struts/proposals"
+        image="images/struts.gif">
+
+    <title>Proposals - Apache Struts Framework</title>
+
+    <menu name="Struts">
+        <item name="Welcome"                 href="../index.html"/>
+	</menu>
+
+</project>
+
+
+
+
+
+
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.0.1.xml b/build-legacy/core/xdocs/proposals/release-plan-1.0.1.xml
new file mode 100644
index 0000000..b9ca663
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.0.1.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.0.1.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.0.1)</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.0.1</strong> release is to provide
+  an official release of all the bug fixes and documentation updates that have
+  been made to the STRUTS_1_0_BRANCH branch since the release of Struts 1.0.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>Since the release of Struts 1.0, a number of important bugs have been
+  fixed, and some notable improvements have been made to the documentation.
+  Currently, these updates are available only to those people who are willing
+  to obtain the source code from CVS and build their own version of Struts.
+  This release will make these updates available in an official distribution,
+  thus making them available to a wider audience.</p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.0.1:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Wednesday, November 21, 2001</li>
+  <li><em>Release Manager</em> - Martin Cooper</li>
+  <li><em>Release Announcement</em> - To the following mailing lists and
+      web sites:
+      <ul>
+      <li>announcements@jakarta.apache.org</li>
+      <li>struts-dev@jakarta.apache.org</li>
+      <li>struts-user@jakarta.apache.org</li>
+      <li>jsp-interest@java.sun.com</li>
+      <li>servlet-interest@java.sun.com</li>
+      <li><a href="http://www.freshmeat.net">http://www.freshmeat.net</a></li>
+      </ul></li>
+  </ul>
+
+  </section>
+
+
+  <section name="Release Criteria" href="Criteria">
+
+  <p>Prior to the release of Struts 1.0.1, the following action items
+  must be completed:</p>
+  <ul>
+  <li>The Struts 1.0.1 Release Notes document shall be updated to describe
+      substantial changes and improvements since the Struts 1.0 release,
+      along with associated updates to the main Struts Documentation
+      Application pages describing the new release.</li>
+  <li>All of the Struts example applications that are included with the release
+      shall operate successfully in the following servlet containers:
+      <ul>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.2.3</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.1</a></li>
+      </ul></li>
+  <li>A release vote shall take place on the <em>struts-dev</em> mailing list
+      to approve this plan.  The release vote MUST pass by "Majority Approval"
+      of Struts committers.</li>
+  </ul>
+
+  </section>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.0b1.xml b/build-legacy/core/xdocs/proposals/release-plan-1.0b1.xml
new file mode 100644
index 0000000..b3f0287
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.0b1.xml
@@ -0,0 +1,88 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.0b1.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.0-beta-1)</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.0-beta-1</strong> release is to
+  create a milestone release against which a final series of bug fixes and
+  documentation updates can occur before a <strong>Struts 1.0 Final</strong>
+  release is created.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>The code base for Struts has been in an informal "feature freeze" for
+  several weeks, while development focus has been on bug fixes and the
+  completion of required documentation.  Both of these goals have been
+  substantially achieved, so it is time for a formal beta release - with
+  the goal of moving quickly to a final <strong>Struts 1.0</strong> release
+  shortly thereafter, if no disabling defects are found.</p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.0-beta-1:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Wednesday, February 21, 2001</li>
+  <li><em>Release Manager</em> - Craig McClanahan</li>
+  <li><em>Release Announcement</em> - To the following mailing lists and
+      web sites:
+      <ul>
+      <li>ANNOUNCEMENTS@JAKARTA.APACHE.ORG</li>
+      <li>GENERAL@JAKARTA.APACHE.ORG</li>
+      <li>STRUTS-DEV@JAKARTA.APACHE.ORG</li>
+      <li>STRUTS-USER@JAKARTA.APACHE.ORG</li>
+      <li>JSP-INTEREST@JAVA.SUN.COM</li>
+      <li>SERVLET-INTEREST@JAVA.SUN.COM</li>
+      <li><a href="http://www.freshmeat.net">http://www.freshmeat.net</a></li>
+      </ul></li>
+  </ul>
+
+  </section>
+
+
+  <section name="Release Criteria" href="Criteria">
+
+  <p>Prior to the release of Struts 1.0-beta-1, the following action items
+  must be completed:</p>
+  <ul>
+  <li>All <a href="http://issues.apache.org/bugzilla/">Bugzilla</a> bug reports
+      against Struts 1.0 nightly builds MUST be marked as "Resolved", with any
+      of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+      REMIND, WORKSFORME).</li>
+  <li>Bug reports that are resolved as LATER or REMIND will include comments
+      as to whether those specific issues will be dealt with in a subsequent
+      1.0 beta or final release, or whether they will be scheduled for
+      consideration in a subsequent release time frame.</li>
+  <li>Any remaining items on the Struts 1.0 TODO list shall be completed.</li>
+  <li>The Struts 1.0 Release Notes document shall be updated to describe
+      substantial changes and improvements since the Struts 0.5 release,
+      along with associated updates to the main Struts Documentation
+      Application pages describing the new release.</li>
+  <li>All of the Struts example applications that are included with the release
+      shall operate successfully in the following servlet containers:
+      <ul>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.2.1</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0</a> (Current
+          nightly build)</li>
+      </ul></li>
+  <li>A release vote shall take place on the STRUTS-DEV mailing list to
+      approve this plan.  The release vote MUST pass by "Majority Approval"
+      of Struts committers.</li>
+  </ul>
+
+  </section>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.1.xml b/build-legacy/core/xdocs/proposals/release-plan-1.1.xml
new file mode 100644
index 0000000..0c21717
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.1.xml
@@ -0,0 +1,129 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1rc2.xml">
+
+    <properties>
+       <title>Struts Release Plan (Version 1.1)</title>
+     </properties>
+
+  <body>
+
+      <section name="Objective" href="Objective">
+
+          <p>
+              $Id$
+          </p>
+
+          <p>
+              The objective of the <strong>Struts 1.1 Final</strong> release is to provide
+              an official release of all the bug fixes and documentation updates that have
+              been made to the main trunk of the jakarta-struts CVS since the release of
+              Struts 1.0.2.
+          </p>
+
+      </section>
+
+      <section name="The Plan" href="Plan">
+
+          <p>
+              Only minor changes have been made to the codebase since the Struts 1.1
+              RC2 release.
+              Issues reported on the few oustanding tickets are either unconfirmed or
+              may be categorized as enhancements and can be resolved in short order.
+              Therefore it is time to make the latest code base available as the
+              Struts 1.1 Final Release.
+          </p>
+
+          <p>
+              The final release of Commons FileUpload has been approved and will be
+              available for distribution with Struts 1.1 Final, as required by the
+              Struts 1.1 RC2 release plan.
+          </p>
+
+          <p>
+              Therefore, the following release plan is proposed for Struts 1.1 Final:
+          </p>
+
+          <ul>
+              <li>
+                  <em>Code Freeze / Tag Date</em> - Saturday, June 28, 2003, 23:59:59
+              </li>
+              <li>
+                  <em>Release Manager</em> - Martin Cooper
+              </li>
+              <li>
+                  <em>Release Announcement</em> - To the following mailing lists:
+                  <ul>
+                      <li>announcements@jakarta.apache.org</li>
+                      <li>struts-dev@jakarta.apache.org</li>
+                      <li>struts-user@jakarta.apache.org</li>
+                  </ul>
+              </li>
+          </ul>
+
+          <p>
+              The release process shall follow the same
+              <a href="http://jakarta.apache.org/commons/releases/">general procedures</a>
+              established the Jakarta Commons products.
+          </p>
+
+      </section>
+
+      <section name="Release Criteria" href="Criteria">
+
+          <p>
+              Prior to the release of Struts 1.1 Final Release, the following
+              action items must be completed:
+          </p>
+
+          <ul>
+              <li>
+                  A release vote shall take place on the <em>struts-dev</em> mailing list
+                  to approve this plan. The release vote MUST pass by "Majority Approval"
+                  of Struts committers.
+             </li>
+             <li>
+                The Struts 1.1 Release Notes document shall be updated to describe
+                any substantial changes and improvements since the Struts 1.1 RC2 release,
+                along with associated updates to the main Struts Documentation
+                Application pages describing the new release.
+             </li>
+             <li>
+                All of the Struts example applications that are included with the release
+                shall operate successfully in the following servlet containers:
+                <ul>
+                    <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.3.1</a></li>
+                    <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.6</a></li>
+                    <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.1.18</a></li>
+                 </ul>
+             </li>
+          </ul>
+
+          <p>
+            Prior to the release of a subsequent Struts 1.1 Final release, the
+            following action items must be completed:
+          </p>
+
+          <ul>
+            <li>
+                All
+                <a href="http://issues.apache.org/bugzilla/buglist.cgi?email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=1.1RC2&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;newqueryname=&amp;order=Bug+Number">
+                Bugzilla bug reports</a>
+                against Struts 1.1 RC2 MUST be marked as "Enhancement" or "Resolved", with any
+                of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+                REMIND, WORKSFORME).
+          </li>
+          <li>
+                Bug reports that are resolved as LATER or REMIND will include comments
+                as to whether those specific issues will be dealt with in a subsequent
+                beta, release candidate, or final release, or whether they will be
+                scheduled for consideration in a subsequent release time frame.
+         </li>
+         <li>
+                The final release of Commons-FileUpload 1.0 must be available
+                and made part of the Struts 1.1 Final distribution.
+          </li>
+      </ul>
+
+    </section>
+    </body>
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.1b1.xml b/build-legacy/core/xdocs/proposals/release-plan-1.1b1.xml
new file mode 100644
index 0000000..840483b
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.1b1.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1b1.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.1b1)</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.1 Beta 1</strong> release is to
+  create a milestone release against which a final series of bug fixes and
+  documentation updates can occur before a <strong>Struts 1.1 Final</strong>
+  release is created.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>Many new features have been added to the nightly builds since the release
+  of Struts 1.0, and many bugs have been fixed. Several of the new features are
+  in high demand by current Struts users, and so it is time to start the process
+  of making this new code base available as a formal release. The first step in
+  this process is an initial beta release, with the goal of moving towards a
+  release candidate and then a final <strong>Struts 1.1</strong> release as
+  soon as is practicable.</p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.1 Beta 1:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Monday, March 18, 2002</li>
+  <li><em>Release Manager</em> - Martin Cooper</li>
+  <li><em>Release Announcement</em> - To the following mailing lists:
+      <ul>
+      <li>announcements@jakarta.apache.org</li>
+      <li>struts-dev@jakarta.apache.org</li>
+      <li>struts-user@jakarta.apache.org</li>
+      </ul></li>
+  </ul>
+
+  </section>
+
+
+  <section name="Release Criteria" href="Criteria">
+
+  <p>Prior to the release of Struts 1.1 Beta 1, the following action items
+  must be completed:</p>
+  <ul>
+  <li>The Struts 1.1 Release Notes document shall be updated to describe
+      substantial changes and improvements since the Struts 1.0.2 release,
+      along with associated updates to the main Struts Documentation
+      Application pages describing the new release.</li>
+  <li>All of the Struts example applications that are included with the release
+      shall operate successfully in the following servlet containers:
+      <ul>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.3</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.3</a></li>
+      </ul></li>
+  <li>A release vote shall take place on the STRUTS-DEV mailing list to
+      approve this plan.  The release vote MUST pass by "Majority Approval"
+      of Struts committers.</li>
+  </ul>
+
+  <p>Prior to the release of a subsequent Struts 1.1 release candidate, the
+  following action items must be completed:</p>
+  <ul>
+  <li>All <a href="http://issues.apache.org/bugzilla/">Bugzilla</a> bug reports
+      against Struts 1.1 nightly builds MUST be marked as "Resolved", with any
+      of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+      REMIND, WORKSFORME).</li>
+  <li>Bug reports that are resolved as LATER or REMIND will include comments
+      as to whether those specific issues will be dealt with in a subsequent
+      release candidate, or final release, or whether they will be scheduled
+      for consideration in a subsequent release time frame.</li>
+  </ul>
+
+  </section>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.1b2.xml b/build-legacy/core/xdocs/proposals/release-plan-1.1b2.xml
new file mode 100644
index 0000000..a1d9b38
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.1b2.xml
@@ -0,0 +1,144 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1-b2.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.1-b2)</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.1 Beta 2</strong> release is to
+  create a milestone release against which a final series of bug fixes and
+  documentation updates can occur before a <strong>Struts 1.1 Final</strong>
+  release is created.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>A number of new features have been added to the nightly builds since the
+  first Beta release of Struts 1.1, and many bugs have been fixed. It is time,
+  therefore, to take the next step in the release process, and make the latest
+  code base available as a second Beta release. The goal is to move towards a
+  release candidate and then a final <strong>Struts 1.1</strong> release as
+  soon as is practicable.</p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.1 Beta 2:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Saturday, August 10, 2002</li>
+  <li><em>Release Manager</em> - Martin Cooper</li>
+  <li><em>Release Announcement</em> - To the following mailing lists:
+      <ul>
+      <li>announcements@jakarta.apache.org</li>
+      <li>struts-dev@jakarta.apache.org</li>
+      <li>struts-user@jakarta.apache.org</li>
+      </ul></li>
+  </ul>
+
+  </section>
+
+
+  <section name="Release Criteria" href="Criteria">
+
+  <p>Prior to the release of Struts 1.1 Beta 2, the following action items
+  must be completed:</p>
+  <ul>
+  <li>The Struts 1.1 Release Notes document shall be updated to describe
+      substantial changes and improvements since the Struts 1.0.2 release,
+      along with associated updates to the main Struts Documentation
+      Application pages describing the new release.</li>
+  <li>All of the Struts example applications that are included with the release
+      shall operate successfully in the following servlet containers:
+      <ul>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.3.1</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.4</a></li>
+      </ul></li>
+  <li>A release vote shall take place on the STRUTS-DEV mailing list to
+      approve this plan.  The release vote MUST pass by "Majority Approval"
+      of Struts committers.</li>
+  </ul>
+
+  <p>Prior to the release of a subsequent Struts 1.1 release candidate, the
+  following action items must be completed:</p>
+  <ul>
+  <li>All <a href="http://issues.apache.org/bugzilla/">Bugzilla</a> bug reports
+      against Struts 1.1 nightly builds MUST be marked as "Resolved", with any
+      of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+      REMIND, WORKSFORME).</li>
+  <li>Bug reports that are resolved as LATER or REMIND will include comments
+      as to whether those specific issues will be dealt with in a subsequent
+      beta, release candidate, or final release, or whether they will be
+      scheduled for consideration in a subsequent release time frame.</li>
+  </ul>
+
+  </section>
+
+
+  <section name="Bugs To Be Addressed" href="Bugs">
+
+  <p>The following bugs must be addressed before Final Release of Struts 1.1.</p>
+
+  <table class="noborder">
+    <tr>
+      <td colspan="2"><strong>Custom Tags</strong></td>
+    </tr>
+    <tr>
+      <td>1586</td>
+      <td>The &lt;html:form&gt; tag generates incorrect focus javascript for radio buttons.</td>
+    </tr>
+    <tr>
+      <td colspan="2"><strong>Documentation</strong></td>
+    </tr>
+    <tr>
+      <td>10537</td>
+      <td>[:TODO:] sections (18)</td>
+    </tr>
+    <tr>
+      <td colspan="2"><strong>Example Webapps</strong></td>
+    </tr>
+    <tr>
+      <td>10955</td>
+      <td>Error running struts-blank applicaiton under JRun 3.1</td>
+    </tr>
+    <tr>
+      <td colspan="2"><strong>Validator Framework</strong></td>
+    </tr>
+    <tr>
+      <td>7353</td>
+      <td>Validator JavaScript Select Error</td>
+    </tr>
+    <tr>
+      <td>10191</td>
+      <td>Validator range checking bug</td>
+    </tr>
+    <tr>
+      <td>10348</td>
+      <td>Validator is not available under module</td>
+    </tr>
+    <tr>
+      <td>10349</td>
+      <td>Validator: date validation does not allow blank input?</td>
+    </tr>
+    <tr>
+      <td>10432</td>
+      <td>DynaValidatorActionForm does not validate data</td>
+    </tr>
+    <tr>
+      <td>10584</td>
+      <td>Not all validation files are read in Validation PlugIn</td>
+    </tr>
+  </table>
+
+  </section>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.1b3.xml b/build-legacy/core/xdocs/proposals/release-plan-1.1b3.xml
new file mode 100644
index 0000000..f245974
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.1b3.xml
@@ -0,0 +1,257 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1-b3.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.1-b3)</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.1 Beta 3</strong> release is to
+  create a milestone release against which a final series of bug fixes and
+  documentation updates can occur before a <strong>Struts 1.1 Final</strong>
+  release is created.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>A number of new features have been added to the nightly builds since the
+  second Beta release of Struts 1.1, and many bugs have been fixed. It is time,
+  therefore, to take the next step in the release process, and make the latest
+  code base available as a third Beta release. The goal is to move towards a
+  release candidate and then a final <strong>Struts 1.1</strong> release as
+  soon as is practicable.</p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.1 Beta 3:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Sunday, December 29, 2002, 23:59:59</li>
+  <li><em>Release Manager</em> - Martin Cooper</li>
+  <li><em>Release Announcement</em> - To the following mailing lists:
+      <ul>
+      <li>announcements@jakarta.apache.org</li>
+      <li>struts-dev@jakarta.apache.org</li>
+      <li>struts-user@jakarta.apache.org</li>
+      </ul></li>
+  </ul>
+
+  </section>
+
+
+  <section name="Release Criteria" href="Criteria">
+
+  <p>Prior to the release of Struts 1.1 Beta 3, the following action items
+  must be completed:</p>
+  <ul>
+  <li>The Struts 1.1 Release Notes document shall be updated to describe
+      substantial changes and improvements since the Struts 1.0.2 release,
+      along with associated updates to the main Struts Documentation
+      Application pages describing the new release.</li>
+  <li>All of the Struts example applications that are included with the release
+      shall operate successfully in the following servlet containers:
+      <ul>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.3.1</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.6</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.1.18</a></li>
+      </ul></li>
+  <li>A release vote shall take place on the STRUTS-DEV mailing list to
+      approve this plan.  The release vote MUST pass by "Majority Approval"
+      of Struts committers.</li>
+  </ul>
+
+  <p>Prior to the release of a subsequent Struts 1.1 release candidate, the
+  following action items must be completed:</p>
+  <ul>
+  <li>All <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=VERIFIED&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=Nightly+Build&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;newqueryname=&amp;order=Bug+Number">Bugzilla bug reports</a>
+      against Struts 1.1 nightly builds MUST be marked as "Resolved", with any
+      of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+      REMIND, WORKSFORME).</li>
+  <li>Bug reports that are resolved as LATER or REMIND will include comments
+      as to whether those specific issues will be dealt with in a subsequent
+      beta, release candidate, or final release, or whether they will be
+      scheduled for consideration in a subsequent release time frame.</li>
+  </ul>
+
+  </section>
+
+
+  <section name="Bugs To Be Addressed" href="Bugs">
+
+  <p>
+      The following bugs must be addressed before Final Release of Struts 1.1.
+      Checked items have been resolved.
+  </p>
+
+  <table class="noborder">
+
+    <!-- Custom tags -->
+    <tr>
+      <td colspan="3"><strong>Custom Tags</strong></td>
+    </tr>
+    <tr>
+      <td>[x]</td>
+      <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=11021">11021</a>
+      </td>
+      <td>ActionForward or &lt;html:link&gt; tag does not support absolute URIs</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=12302">12302</a></td>
+      <td>Sporadic error in html:form action attribute</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=13645">13645</a></td>
+      <td>Add action attribute to &lt;html:link&gt;</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15044">15044</a></td>
+      <td>Taglib - Index Attribute in html:Checkbox doesn't set correctly</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15196">15196</a></td>
+      <td>Bug on the RequestUtils.computeParameters using a DynaValidatorForm as map of the parameter</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15451">15451</a></td>
+      <td>Multiple mapped properties not possible / Direct maps and indexes not possible</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15601">15601</a></td>
+      <td>tile examples to move to standard webapp location</td>
+    </tr>
+
+    <!-- Controller -->
+    <tr>
+      <td colspan="3"><strong>Controller</strong></td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=12871">12871</a></td>
+      <td>ExceptionHandler does not obey controller inputForward rule</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=14054">14054</a></td>
+      <td>Rename "Application" components to "Module"</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=14749">14749</a></td>
+      <td>Action "input" not starting with '/' and not a valid forward will cause an internal server error</td>
+    </tr>
+
+    <!-- Documentation -->
+    <tr>
+      <td colspan="3"><strong>Documentation</strong></td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=10537">10537</a></td>
+      <td>[:TODO:] sections</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15167">15167</a></td>
+      <td>Updated Action documentation</td>
+    </tr>
+
+    <!-- Utilities -->
+    <tr>
+      <td colspan="3"><strong>Utilities</strong></td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=11932">11932</a></td>
+      <td>(Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment</td>
+    </tr>
+
+    <!-- Unknown -->
+    <tr>
+      <td colspan="3"><strong>Unknown</strong></td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=14042">14042</a></td>
+      <td>Unknown Memory leaks with JBoss 3.x +(Tomcat/Jetty)</td>
+    </tr>
+
+    <!-- Post Mortem -->
+    <tr>
+      <td colspan="3"><strong>Post Mortem -- These tickets were added after the release of Struts 1.1 B3 and need to be resolved before the next iteration</strong></td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15736">15736</a></td>
+      <td>Struts doesn't initialize under strict security manager</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15799">15799</a></td>
+      <td>Nested tags picks up wrong bean for values</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=15883">15883</a></td>
+      <td>wrong resource file used in multi-application context</td>
+    </tr>
+    <tr>
+        <td>[x]</td>
+        <td>
+          <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=16019">16019</a></td>
+      <td>LookupDispatchAction multiple MessageResources</td>
+    </tr>
+      <tr>
+          <td>[x]</td>
+          <td>
+            <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=16514">16514</a></td>
+        <td>NestedtTiles fail in this release</td>
+      </tr>
+      <tr>
+          <td>[x]</td>
+          <td>
+            <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=16603">16603</a></td>
+        <td>internalModuleRelativeForward() doesn't treat module-relative paths as defined by forwardPattern</td>
+      </tr>
+      <tr>
+          <td>[x]</td>
+          <td>
+            <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=16609">16609</a></td>
+        <td>MessageResource not in request scope for Module</td>
+      </tr>
+  </table>
+
+  </section>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.1rc1.xml b/build-legacy/core/xdocs/proposals/release-plan-1.1rc1.xml
new file mode 100644
index 0000000..c316525
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.1rc1.xml
@@ -0,0 +1,86 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1rc1.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.1-rc1)</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.1 Release Candidate 1</strong>
+  release is to create a milestone release in preparation for an imminent
+  <strong>Struts 1.1 Final</strong> release. As a release candidate, this
+  milestone release currently contains no known showstoppers.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>A number of bugs have been fixed since the third Beta release of Struts 1.1,
+  and all remaining bugs have been categorized either as enhancements, or as
+  problems which can be fixed in a release subsequent to Struts 1.1 Final.
+  Therefore it is time to make the latest code base available as a first Release
+  Candidate. The goal is to move towards a final <strong>Struts 1.1</strong>
+  release as soon as is practicable.</p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.1 Release Candidate 1:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Tuesday, February 18, 2003, 23:59:59</li>
+  <li><em>Release Manager</em> - Martin Cooper</li>
+  <li><em>Release Announcement</em> - To the following mailing lists:
+      <ul>
+      <li>announcements@jakarta.apache.org</li>
+      <li>struts-dev@jakarta.apache.org</li>
+      <li>struts-user@jakarta.apache.org</li>
+      </ul></li>
+  </ul>
+
+  </section>
+
+
+  <section name="Release Criteria" href="Criteria">
+
+  <p>Prior to the release of Struts 1.1 Release Candidate 1, the following
+  action items must be completed:</p>
+  <ul>
+  <li>The Struts 1.1 Release Notes document shall be updated to describe
+      substantial changes and improvements since the Struts 1.0.2 release,
+      along with associated updates to the main Struts Documentation
+      Application pages describing the new release.</li>
+  <li>All of the Struts example applications that are included with the release
+      shall operate successfully in the following servlet containers:
+      <ul>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.3.1</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.6</a></li>
+      <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.1.18</a></li>
+      </ul></li>
+  <li>A release vote shall take place on the STRUTS-DEV mailing list to
+      approve this plan.  The release vote MUST pass by "Majority Approval"
+      of Struts committers.</li>
+  </ul>
+
+  <p>Prior to the release of a subsequent Struts 1.1 Final release, the
+  following action items must be completed:</p>
+  <ul>
+  <li>All <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=VERIFIED&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=Nightly+Build&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;newqueryname=&amp;order=Bug+Number">Bugzilla bug reports</a>
+      against Struts 1.1 nightly builds MUST be marked as "Resolved", with any
+      of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+      REMIND, WORKSFORME).</li>
+  <li>Bug reports that are resolved as LATER or REMIND will include comments
+      as to whether those specific issues will be dealt with in a subsequent
+      beta, release candidate, or final release, or whether they will be
+      scheduled for consideration in a subsequent release time frame.</li>
+  </ul>
+
+  </section>
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan-1.1rc2.xml b/build-legacy/core/xdocs/proposals/release-plan-1.1rc2.xml
new file mode 100644
index 0000000..e6907d4
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan-1.1rc2.xml
@@ -0,0 +1,120 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1rc2.xml">
+
+  <properties>
+    <title>Struts Release Plan (Version 1.1-rc2)</title>
+  </properties>
+
+  <body>
+
+  <section name="Objective" href="Objective">
+
+  <p>$Id$</p>
+
+  <p>The objective of the <strong>Struts 1.1 Release Candidate 2</strong>
+  release is to create a milestone release in preparation for an imminent
+  <strong>Struts 1.1 Final</strong> release. As a release candidate, this
+  milestone release currently contains no known showstoppers.</p>
+
+  </section>
+
+
+  <section name="The Plan" href="Plan">
+
+  <p>A number of bugs have been fixed since and other internal changes made
+  since the first release candidate of Struts 1.1.
+  All remaining tickets have been categorized either as enhancements, or as
+  problems which can be fixed in a release subsequent to Struts 1.1 Final.
+  Therefore it is time to make the latest code base available as a first Release
+  Candidate. The goal is to move towards a final <strong>Struts 1.1</strong>
+  release as soon as is practicable. </p>
+
+      <p>
+          This release candidate includes the Commons FileUpload RC1 JAR,
+          which is required to compile and use Struts 1.1.
+          A final release of Struts must depend only on final releases of other
+          required products. Consequently, the Struts 1.1 Final release cannot
+          be made unitl the Commons FileUpload 1.0 Final Release is available.
+      </p>
+
+      <p>
+          However, Pending the final release of Commons FileUpload 1.0,
+          and should there be no showstoppers found in this release candidate,
+          <strong>Sunday June 29, 2003</strong>, is set as the anticipated release date of
+          Struts 1.1 Final.
+          Anyone wishing to test the product before the final release
+          is encourged to do so before that date.
+      </p>
+
+  <p>Therefore, the following release plan is proposed for Struts 1.1 Release Candidate 2:
+  </p>
+  <ul>
+  <li><em>Code Freeze / Tag Date</em> - Friday, June 6, 2003, 23:59:59</li>
+  <li><em>Release Manager</em> - Ted Husted</li>
+  <li><em>Release Announcement</em> - To the following mailing lists:
+      <ul>
+      <li>announcements@jakarta.apache.org</li>
+      <li>struts-dev@jakarta.apache.org</li>
+      <li>struts-user@jakarta.apache.org</li>
+      </ul></li>
+  </ul>
+
+      <p>
+          This plan is being prepared and executed in accordance with a positive vote
+          held on the STRUT-DEV list, beginning on May 29,
+          the results of which were posted on June 3, 2003.
+      </p>
+
+      <p>
+          The release process shall follow the same
+          <a href="http://jakarta.apache.org/commons/releases/">general procedures</a>
+          established the Jakarta Commons products.
+      </p>
+
+  </section>
+
+      <section name="Release Criteria" href="Criteria">
+
+      <p>Prior to the release of Struts 1.1 Release Candidate 2, the following
+      action items must be completed:</p>
+      <ul>
+      <li>The Struts 1.1 Release Notes document shall be updated to describe
+          substantial changes and improvements since the Struts 1.1 RC1 release,
+          along with associated updates to the main Struts Documentation
+          Application pages describing the new release.</li>
+      <li>All of the Struts example applications that are included with the release
+          shall operate successfully in the following servlet containers:
+          <ul>
+          <li><a href="http://jakarta.apache.org/tomcat">Tomcat 3.3.1</a></li>
+          <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.0.6</a></li>
+          <li><a href="http://jakarta.apache.org/tomcat">Tomcat 4.1.18</a></li>
+          </ul></li>
+      <!--
+      <li>A release vote shall take place on the STRUTS-DEV mailing list to
+          approve this plan.  The release vote MUST pass by "Majority Approval"
+          of Struts committers.  </li>
+      -->
+      </ul>
+
+      <p>Prior to the release of a subsequent Struts 1.1 Final release, the
+      following action items must be completed:</p>
+      <ul>
+      <li>All
+          <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=VERIFIED&amp;bug_severity=Blocker&amp;bug_severity=Critical&amp;bug_severity=Major&amp;bug_severity=Normal&amp;bug_severity=Minor&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=Nightly+Build&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;newqueryname=&amp;order=Bug+Number">
+          Bugzilla bug reports</a>
+          against Struts 1.1 nightly builds MUST be marked as "Enhancement" or "Resolved", with any
+          of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER,
+          REMIND, WORKSFORME).</li>
+      <li>Bug reports that are resolved as LATER or REMIND will include comments
+          as to whether those specific issues will be dealt with in a subsequent
+          beta, release candidate, or final release, or whether they will be
+          scheduled for consideration in a subsequent release time frame.</li>
+          <li>
+              The final release of Commons-FileUpload 1.0 must be available
+              and made part of the Struts 1.1 Final distribution.
+          </li>
+      </ul>
+
+    </section>
+    </body>
+</document>
diff --git a/build-legacy/core/xdocs/proposals/release-plan_1_2_0.xml b/build-legacy/core/xdocs/proposals/release-plan_1_2_0.xml
new file mode 100644
index 0000000..2d8e254
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/release-plan_1_2_0.xml
@@ -0,0 +1,182 @@
+<?xml version="1.0"?>
+<document url="./release-plan-1.1rc2.xml">
+
+    <properties>
+        <title>Struts Release Plan (Version 1.2.0)</title>
+     </properties>
+
+  <body>
+
+      <section name="Objective" href="objective">
+          <p>
+              $Id$
+          </p>
+
+          <p>
+              THIS IS AN UNRATIFIED DRAFT DOCUMENT PROVIDED FOR DISCUSSION PURPOSES ONLY!
+          </p>
+
+          <p>
+              The objective of the <strong>Struts 1.2.0</strong> release is to provide an official version of all the
+              changes that have been made to the main trunk of the jakarta-struts CVS since the release of Struts 1.1
+              Final.
+          </p>
+      </section>
+
+      <section name="The Plan" href="plan">
+          <p>
+              Since the release of version Struts 1.1 Final, we have removed many of the elements deprecated between
+              Struts 1.0 and Struts 1.1 and made several bug fixes and minor enhancements.
+          </p>
+
+          <p>
+              The following release plan is proposed for Struts 1.2.0:
+          </p>
+
+          <ul>
+              <li>
+                  <em>Tag Date</em> - Saturday, September 7, 2003, 23:59:59
+              </li>
+              <li>
+                  <em>Release Manager</em> - Ted Husted
+              </li>
+              <li>
+                  <em>Alpha Release Announcement</em> - To the following mailing list:
+                  <ul>
+                      <li>struts-dev@jakarta.apache.org</li>
+                  </ul>
+              </li>
+              <li>
+                  <em>Beta/General Release Announcement</em> - To the following mailing lists:
+                  <ul>
+                      <li>struts-dev@jakarta.apache.org</li>
+                      <li>struts-user@jakarta.apache.org</li>
+                      <li>announcements@jakarta.apache.org</li>
+                  </ul>
+              </li>
+          </ul>
+
+          <p>
+              The release process shall follow the same general procedures established for the
+              <a href="http://httpd.apache.org/dev/release.html">Apache HTTPD project</a> and
+              <a href="http://jakarta.apache.org/commons/releases/">Jakarta Commons products</a>, and utilize the
+              HTTPD numbering scheme.
+          </p>
+
+          <p>
+              The release will initially be given an Alpha status and made available through the Release Manager's home
+              directory.
+              Pursuant to a Majority Vote on the <em>struts-dev</em> Mailing List, the release may be moved to the
+              public release directory.
+              The vote may also serve to reclassify the release to be of <strong>Beta</strong> or <strong>General Availability</strong> (GA)
+              quality, as defined by the Apache HTTPD project.
+              Subsequent votes may reclassify the release, either to promote it or to demote it, as need be.
+          </p>
+      </section>
+
+      <section name="Specific Release Criteria" href="specific">
+          <p>
+              Prior to the <strong>Struts 1.2.0 release</strong>, these specific action items must be completed:
+          </p>
+
+          <ul>
+              <li>
+                  The Roadmap page must be updated with an explanation of the new release numbering scheme.
+              </li>
+          </ul>
+      </section>
+
+      <section name="Standard Release Criteria" href="standard">
+          <p>
+              Prior to <strong>any release</strong> by the Struts Committers, including this one, the following action items must
+              be completed:
+          </p>
+
+          <ul>
+              <li>
+                  <strong>Resolve showstoppers.</strong>
+                  Relevant
+                  <a href="http://issues.apache.org/bugzilla/buglist.cgi?email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=1.1RC2&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;newqueryname=&amp;order=Bug+Number">
+                  Bugzilla tickets</a> verified by a Struts Committer to have the Severity BLOCKER, CRITICAL, or
+                  MAJOR must be "Resolved" with one of these Bugzilla resolutions: FIXED, INVALID, WONTFIX, WORKSFORME.
+              </li>
+              <li>
+                  <strong>Apply patches.</strong>
+                  Relevant
+                  <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=VERIFIED&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=PatchAvailable&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=Bug+Number">
+                  Bugzilla reports</a> which include a working patch must be "Resolved" with any of the legal Bugzilla
+                  resolutions (FIXED, INVALID, WONTFIX, LATER, REMIND, WORKSFORME).
+                  <ul>
+                      <li>
+                          Bug reports with patches that are resolved as LATER or REMIND shall include an explanation as
+                          to why the patch should be applied in a later release.
+                      </li>
+                  </ul>
+              </li>
+              <li>
+                  <strong>Test example applications.</strong>
+                  All example applications included with the release shall operate successfully under the
+                  Reference Implementation containers for the Servlet/JSP specifications supported by the release.
+                  In the case of a Struts 1.x.x release, these containers are:
+                  <ul>
+                      <li>
+                          Tomcat 3.3 (Servlet/JSP 2.2/1.1 Reference Implementation)
+                      </li>
+                      <li>
+                          Tomcat 4.1 (Servlet/JSP 2.3/1.2 Reference Implementation)
+                      </li>
+                  </ul>
+                      The best available version of each container shall be used, as documented by the
+                      <a href="http://jakarta.apache.org/tomcat">Tomcat website</a> at the time the test is conducted.
+              </li>
+              <li>
+                  <strong>Update Release Notes.</strong> The Release Notes for the distribution shall be updated to summarize any
+                  substantial changes and improvements since the prior release, including updates to bundled
+                  documentation and example applications.
+              </li>
+            </ul>
+      </section>
+
+      <section name="Minor Release Criteria" href="minor">
+          <p>
+            Prior to an initial <strong>Struts minor release</strong> (#.#.0), the following action items must be completed:
+          </p>
+
+          <ul>
+              <li>
+                  <strong>Review pending issues.</strong>
+                  All relevant
+                  <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=LATER&amp;resolution=REMIND&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=Bug+Number">
+                  Bugzilla reports marked "Resolved" with the Resolutions LATER or REMIND</a> shall be reviewed to
+                  ensure that pending issues have been addressed prior to the release.
+              </li>
+              <li>
+                  <strong>Review pending enhancements.</strong>
+                  All relevant
+                  <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=VERIFIED&amp;bug_severity=Enhancement&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=Bug+Number">
+                  Bugzilla reports marked "Enhancement"</a> shall be reviewed by the Release Manager to ensure that
+                  all suitable enhancements have been made prior to the release.
+              </li>
+              <li>
+                  <strong>Resolve new issues.</strong>
+  	              All relevant
+	              <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_status=VERIFIED&amp;bug_severity=Blocker&amp;bug_severity=Critical&amp;bug_severity=Major&amp;bug_severity=Normal&amp;bug_severity=Minor&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=Bug+Number">
+	              Bugzilla tickets</a> MUST be marked as "Enhancement" or "Resolved" with any
+	              of the legal Bugzilla resolutions (FIXED, INVALID, WONTFIX, LATER, REMIND, WORKSFORME).
+                  <ul>
+                      <li>
+                          Bug reports that are resolved as LATER or REMIND will include comments as to whether those
+                          specific issues will be dealt with in a forthcoming minor release or whether they will be
+                          considered in a future major release.
+                     </li>
+                  </ul>
+              </li>
+              <li>
+                  A Majority Vote shall take place on the <em>struts-dev</em> mailing list to approve a release plan
+                  for the initial minor release.
+              </li>
+          </ul>
+    </section>
+
+    </body>
+</document>
diff --git a/build-legacy/core/xdocs/proposals/struts-faces.xml b/build-legacy/core/xdocs/proposals/struts-faces.xml
new file mode 100644
index 0000000..4e3b133
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/struts-faces.xml
@@ -0,0 +1,300 @@
+<?xml version="1.0"?>
+<document url="./struts-faces-1.xml">
+
+  <properties>
+    <title>About Struts and JavaServer Faces [forward-looking]</title>
+  </properties>
+
+  <body>
+
+<section name="background" href="Background">
+<p>
+[18-Sep-2002] JavaServer Faces (JSF) is being developed as JSR 127 under the Java
+Community Process, with the goal of creating a standard framework for user
+interface components to be used in web applications.  Included will be the
+following basic features:
+</p>
+
+<ul>
+<li>
+  User interface component model
+</li>
+
+<li>
+  Event handling model
+</li>
+
+<li>
+  Validation framework
+</li>
+
+<li>
+  Flexible rendering model (plugin support for rendering different
+  kinds of HTML, or different markup languages and technologies)
+</li>
+
+<li>
+  A standard RenderKit (and associated Renderers) for generating basic
+  HTML/4.01 markup.  This library is primarily for making JSF useful
+  out of the box, and allow apps to be portable across JSF
+  implementations.  However, we expect a lot of innovation in this
+  area among competing JSF implementations.
+</li>
+</ul>
+
+<p>
+All of the above functionality is available via standard Java APIs, and is
+thus not tied to JavaServer Pages (JSP).  However, because a large
+majority of JSF users will also be using JSP, an additional set of
+requirements is included in the JSF specification, including:
+</p>
+
+<ul>
+<li>
+  A standard tag library for generic things that are independent of
+  the specific RenderKit in use (such as adding a validator to a
+  component).
+</li>
+
+<li>
+  A standard tag library for the basic HTML RenderKit, with a tag for
+  each combination of a component type and a method of rendering that
+  component type.  An example will make this clearer -- consider the
+  UISelectOne component, which represents a list of options, and allows
+  only a single option from the list to be selected.  Such a component
+  can be rendered in three different ways (in the basic HTML RenderKit),
+  each with a different Renderer and a corresponding custom tag:<br/>
+
+  &lt;h:selectone_listbox> - Display a list of all the possible
+  options (expanding the box to include all of them so that no scrollbar
+  is required).<br/>
+
+  &lt;h:selectone_menu> -  Display as a combo box (the traditional HTML
+  &lt;select> element with size="1").<br/>
+
+  &lt;h:selectone_radio> - Display as a set of radio buttons and
+  corresponding labels.
+</li>
+</ul>
+
+<p>
+Note that the application developer doesn't know or care which mechanism
+was used to display this component -- that's up to the page author, who
+will pick the desired representation by virtue of which tag he or she
+selects (at the Java API level, you make this choice by setting the
+"rendererType" property on the component instance).  This is one of the
+many advances that JSF provides over Struts tags, where there is one and
+only one way to render each individual element.
+</p>
+
+<p>
+There are also provisions for creating more complex components like grids,
+tree controls, and the like -- a common theme you will see is "compose
+complex things out of little things" -- that is accomplished in JSP by
+nesting component tags inside each other, just like you nest HTML &lt;input>
+elements inside a &lt;form> element.
+</p>
+
+<p>
+For more information about JavaServer Faces, and an early access draft of
+the specification (and an early access version of the RI that corresponds
+to an even earlier draft of the spec), you'll want to bookmark:
+</p>
+
+<p>
+  <a href="http://java.sun.com/j2ee/javaserverfaces/">http://java.sun.com/j2ee/javaserverfaces/</a>
+</p>
+
+<p>
+In addition, there is a forum on the Java Developer Connection (free
+registration required) focused on JavaServer Faces, so please ask your
+general Faces-related questions there instead of here.  Here's a direct
+link to the forum page:
+</p>
+
+<p>
+  <a href="http://java.sun.com/j2ee/javaserverfaces/">http://forums.java.sun.com/forum.jsp?forum=427</a>
+</p>
+
+<p>
+Note that JavaServer Faces depends on Servlet 2.3 and JSP 1.2 (i.e. J2EE
+1.3 containers).
+</p>
+</section>
+
+<section href="struts" name="How does this affect Struts?">
+<p>
+At first glance, the low level components sound a lot like the struts-html
+tag library that Struts users know and love.  Indeed, there is a very
+substantial amount of overlap.  So, what's going to happen?
+</p>
+
+<p>
+In my JavaOne BOF on Struts (March, 2002), I made the statement that
+Struts would have a very clean integration with JSF, so that you can use
+JSF components in your user interface, but continue to use the controller,
+Actions, and associated business logic.  Indeed, I stated that it will be
+possible to transition your application from using Struts HTML tags to
+using Faces component tags, one page at a time -- in most cases, with zero
+changes to the business logic or Action classes and minimal changes to the
+&lt;forward> elements in your struts-config.xml configuration file.
+</p>
+
+<p>
+Along with developing JavaServer Faces itself (I am the specification lead
+for JSR-127), I have been working on just such an integration library for
+Struts (1.1 only; sorry in advance to 1.0 users).  While not completed
+yet, it is clear that the goals stated in the previous paragraph are
+achievable with the current evolving design of JSF.  While things can
+always change in the future, many JSR-127 expert group members consider
+high quality integration with Struts to be an important success factor for
+JavaServer Faces to be accepted.  Therefore, I do not expect that JSF will
+evolve in ways that make this kind of integration difficult or impossible.
+</p>
+
+<p>
+From the developer's perspective, you will need to do only the following
+to start using JSF components in your pages:
+</p>
+
+<ul>
+<li>
+  Add a new struts-faces.jar file, and the JAR files for an
+  appropriate JSF implementation, to your /WEB-INF/lib directory.
+</li>
+
+<li>
+  Note that JSF and the JSP Standard Tag Library (JSTL) interoperate
+  very nicely, so you will also be able to use JSTL tags in your
+  new pages if you wish to.
+</li>
+
+<li>
+  Add a couple of elements to your web.xml deployment descriptor,
+  corresponding to the requirements outlined in Chapter 9 of the
+  JSF specification.
+</li>
+
+<li>
+  Transition one page at a time to use the new tag libraries,
+  making an appropriate modification to the &lt;forward> elements
+  for your pages (the URL needs to change to meet Faces requirements).
+</li>
+</ul>
+
+<p>
+The integration library will be available as a separately packaged
+download that runs with Struts 1.1, and will include a converted copy of
+the canonical struts-example web application so that you can see exactly
+what had to change in order to use Struts with JSF.
+</p>
+
+<p>
+Besides the integration classes themselves (primarily an implementation of
+the JSF ApplicationHandler API), the library will include some
+Struts-flavored components and renderers that provide functionality
+similar to that provided by the existing struts-html tags, when this is
+not provided by the standard JSF components.  For example, there will be a
+Struts version of the UIForm component that accepts an "action" attribute
+that looks up the corresponding action mapping, and creates the form bean
+as needed, just like the &lt;html:form> tag does today.
+</p>
+
+<p>
+The good news -- development of this integration library is well under
+way.
+</p>
+
+<p>
+The bad news -- you can't see it quite yet.  This is primarily because it
+relies on changes to JSF that have occurred since the early access release
+of the RI was published, so you wouldn't be able to use it anyway.
+However, as soon as it is feasible, this library will be added to the
+"contrib" folder of Struts, with the sources (and downloadable
+distributions) available under the usual Apache license terms.  (The
+source code will also give you a head start at creating your own JSF
+components, too).
+</p>
+</section>
+
+<section href="choices" name="So what user interface technology should i choose?">
+<p>
+Everyone's functionality and schedule requirements are different.
+However, the following points summarize my basic recommendations and
+thoughts about the future:
+</p>
+
+<ul>
+<li>If you have existing Struts-based applications that use the existing
+  HTML tag library, feel free to continue to use them if you wish.
+  Struts 1.1 offers full support for this existing functionality.
+</li>
+
+<li>
+  Once the integration library becomes available, you should do some
+  experimenting and prototyping to determine the effort required to
+  migrate your apps to the new JSF component architecture (I'm betting
+  that the extra functionality you gain by doing this will be well
+  worth the effort in many cases).  As described above, the actual
+  migration can be done piecemeal -- it doesn't need to happen all
+  at once.
+</li>
+
+<li>
+  For applications now (or about to be) under development that have
+  relatively short term schedules (i.e. the next few months), you
+  should probably stick with the existing HTML library.
+</li>
+
+<li>
+  For applications with a longer lead time, seriously consider waiting
+  for the ability to use JSF components instead of the Struts HTML
+  tag library.  Doing this will let you leverage not only the standard
+  HTML components that come with JSF out of the box, but also the rich
+  libraries of JSF components likely to be created by third parties in
+  the future (including Struts developers).
+</li>
+</ul>
+
+<p>
+For Struts after 1.1 is released, the developers haven't yet had formal
+conversations (which will happen on STRUTS-DEV) about what a future Struts
+will look like.  However, I'm going to continue to advocate a long term
+migration to using standards like JSF and JSTL when they are available,
+and de-emphasize the further development of the Struts proprietary tag
+libraries.
+</p>
+
+<p>
+The Struts tag libraries have had a tremendous positive impact on the
+development of the standard Java APIs for user interfaces.  I joked with
+the JSTL spec lead that Struts users would *never* accept JSTL without an
+expression language at least as powerful as the Struts one; and there is
+more than a little truth to that statement :-).  The same thing is
+happening now for the HTML tags -- and it's time for us to start migrating
+to the standards, which gives us the time to focus on extending Struts in
+other directions in the future.
+</p>
+
+<p>
+Comments?  Questions?  If it's about Struts, or Struts/JSF integration,
+feel free to ask about these issues on STRUTS-DEV or STRUTS-USER (although
+I'm going to be relatively incommunicado over the next week; I'll be in
+Yokohama at JavaOne Japan and only intermittently connected to email).
+Questions about JSF itself should be addressed to the JSF forum at the URL
+listed above.
+</p>
+
+<p>
+And thanks to all of you for your continued support and use of Struts --
+the community that has developed around this framework continues to amaze
+and humble me.
+</p>
+
+<p>
+Craig McClanahan
+</p>
+</section>
+</body>
+</document>
+
diff --git a/build-legacy/core/xdocs/proposals/todo-1.0.xml b/build-legacy/core/xdocs/proposals/todo-1.0.xml
new file mode 100644
index 0000000..c18aad4
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/todo-1.0.xml
@@ -0,0 +1,121 @@
+<?xml version="1.0"?>
+<document url="./todo-1.1.xml">
+
+  <properties>
+    <title>The Struts Project TODO List for Version 1.0</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Introduction" href="Intro">
+
+  <p>Application frameworks, like the applications we build with them,
+  never seem to be completed.  The following are the remaining work items
+  before Version 1.0 of Struts can be released.</p>
+
+  <p>The TODO list tasks are divided into functional areas that correspond
+  to the major components of the Struts Framework.  References in square
+  brackets are the Java package containing the corresponding source code.</p>
+
+  </section>
+
+
+  <task-list name="Struts Documentation" href="Docs">
+
+    <info>
+      <p>Omnibus task list for items related to the Struts Documentation,
+      which do not have direct relationships with code bases.</p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="Struts Example Application" href="Example">
+
+    <info>
+      <p>An example web application utilizing the Struts framework and
+      custom tag library.</p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="MVC Framework [org.apache.struts.action]" href="MVC">
+
+    <info>
+      <p>This is the core controller servlet, with support for the developer's
+      action and form bean classes, plus the supporting data structures.</p>
+    </info>
+
+    <task name="Deprecation Warnings">
+      <info>
+        <p>Review framework-wide use of features that have now been
+        deprecated.</p>
+      </info>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="XML Digester [org.apache.struts.digester]" href="Digester">
+
+    <info>
+      <p>The Digester package supports scripted firing of "rules" based on
+      matching a particular pattern of nested XML tags.  Among the predefined
+      rules that can be utilized are rules to create new objects, set bean
+      properties from the contents of attributes, or call arbitrary methods
+      with arguments based on the XML content being parsed.  A common
+      use for this technology (illustrated in the Struts ActionServlet), is
+      parsing configuration files and building corresponding object trees.</p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="Bean Tag Library [org.apache.struts.taglib.bean]"
+             href="BEAN">
+
+    <info>
+      <p>This tag library contains basic tags useful in manipulating JavaBeans
+      and their properties.  It includes support for getting and setting bean
+      properties using simple, nested, and subscripted accessor expressions.
+      </p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="HTML Forms Tag Library [org.apache.struts.taglib.html]"
+             href="HTML">
+
+    <info>
+    <p>This tag library contains tags useful in preparing web applications that
+    use HTML forms as their primary mechanism for user data entry, as well as
+    support for internationalized and localized applications.</p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="Utility Classes" href="Util">
+
+    <info>
+      <p>This package contains a variety of utility classes useful within
+      Struts as well as in stand-alone applications.</p>
+    </info>
+
+    <task name="Update HTML Filtering">
+      <info>
+        <p>Update the filtering supported by <code>BeanUtils.filter()</code>.
+        </p>
+        [STRUTS-DEV, Matthias Kerkhoff, 11/13/2000]
+      </info>
+    </task>
+
+  </task-list>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/todo-1.1.xml b/build-legacy/core/xdocs/proposals/todo-1.1.xml
new file mode 100644
index 0000000..0d9a602
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/todo-1.1.xml
@@ -0,0 +1,608 @@
+<?xml version="1.0"?>
+<document url="./todo-1.1.xml">
+
+  <properties>
+    <title>Features We'd Like To See - The Struts Project Wish List</title>
+  </properties>
+
+  <body>
+
+
+  <section name="Introduction" href="Intro">
+
+  <p>Application frameworks, like the applications we build with them,
+  never seem to be completed.  The following major areas of improvement
+  are being considered for implementation in a future version 
+  of Struts. </p>
+
+  <p>Which features are implemented first depends greatly on 
+  individual developers becoming involved in the process. Many key 
+  features in Struts grew out of code first distributed on the mailing 
+  list. If there is a feature here that you need, or already have, please 
+  start a thread and show us the code!</p>
+
+  <p class="center"><a href="../faqs/helping.html#release"><strong>So, when is the next release coming out?</strong></a></p>
+
+  <p>An external development that is likely to affect the development of
+  Struts 1.1 will be the emerging Standard Tag Library, being produced under
+  the <a href="http://www.jcp.org/jsr/detail/52.jsp">Java Community Process</a>. 
+  A very early release is now available at 
+  <a href="http://jakarta.apache.org/taglibs/doc/jsptl-doc/intro.html">Jakarta 
+  Taglibs</a>.</p>
+
+  <p>The existing Struts tags were used as input to the standardization process,
+  but in the case where standard tags with similar functionality are adopted,
+  we should migrate Struts tags to maintain maximum compatibility with the
+  new standard library.</p>
+
+  </section>
+
+  <section name="Pending Tasks"  href="pending">
+  
+  <ul>
+  <li><a href="workflow.html">Workflow</a></li>
+  <li><a href="http://husted.com/struts/resources/logic-niallp.htm">If/Else/Switch tags</a></li>
+  <li><a href="http://husted.com/struts/resources/codemaker.htm">Code generator</a></li>
+  </ul>
+ 
+  <p>See also the Service Manager packages in the contrib folder.</p>
+
+  <p>The wish list tasks are divided into functional areas that correspond
+  to the major components of the Struts Framework. References in square
+  brackets are the Java package containing the corresponding source code. 
+  Listing a task here is not a guarantee that it will be present in the 
+  next release. Again, whether a wish becomes a feature depends on whether 
+  there are volunteers who choose to work on the task. </p>
+
+  </section>
+
+  <task-list name="Struts Documentation" href="Docs">
+
+    <info>
+      <p>Omnibus task list for items related to the Struts Documentation,
+      which do not have direct relationships with code bases.</p>
+    </info>
+
+    <task name="Taglib Chapters for User Guide">
+    <info>
+     Incorporate the Taglib documentation and Developer Guides into the User Guide, 
+     by including the source of these from their present locations.
+    </info>   
+    </task>
+
+    <task name="TODO stylesheet">
+    <info>
+     Revise TODO stylesheet to add Status and Source elements, and to support mailto 
+     links for volunteers in Assigned element. All elements should support hypertext 
+     links. 
+     </info>   
+    </task>
+
+    <task name="Taglib stylesheet">
+    <info>
+     Add support for "since" element for tracking changes to tags between versions.
+    </info>   
+    </task>
+
+    <task name="Contribution Reviews">
+    <info>
+     Area to post articles about contributions from Struts developers.
+    </info>   
+    </task>
+
+    <task name="Expanded FAQ">
+    <info>
+     Area to post a "choice" FAQ of truly common questions.
+    </info>   
+    </task>
+
+  </task-list>
+
+
+  <task-list name="Struts Example Application" href="Example">
+
+    <info>
+      <p>An example web application utilizing the Struts framework and
+      custom tag library.</p>
+    </info>
+
+    <task name="Better Database Support">
+      <info>
+        <p>Use a "real" database of some sort (while still making Struts
+        easy to install.</p>
+      </info>
+      <assigned>
+        <a href="mailto:husted@apache.org">Ted Husted</a>
+      </assigned>
+
+    </task>
+
+    <task name="Locale Switching">
+      <info>
+        <p>Add support for switching Locales on the fly to the Struts
+        example application.</p>
+      </info>
+      <assigned>
+        <a href="mailto:husted@apache.org">Ted Husted</a>
+      </assigned>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="MVC Framework [org.apache.struts.action]" href="MVC">
+
+    <info>
+      <p>This is the core controller servlet, with support for the developer's
+      action and form bean classes, plus the supporting data structures.</p>
+    </info>
+
+    <task name="Workflow Processing">
+      <info>
+        <p>Create a mechanism by which business logic (now encoded in
+        <code>Action</code> classes) can be subdivided into individual work
+        <code>Tasks</code> that are combined according to configuration
+        information (including flow control and iteration support) in the
+        <code>struts-config.xml</code> file.  Support for workflow processing
+        would be provided by a set of standard <code>Actions</code>, and
+        will offer an alternative mechanism (not a replacement of Actions)
+        to organizing your business logic.</p>
+        <p><a href="proposal-workflow.html"><strong>A Workflow Proposal is pending.</strong></a></p>    
+      </info>
+      <assigned>
+        <a href="mailto:craiger@tataryn.net">Craig Tataryn</a>,
+        <a href="mailto:nic.hobbs@uk.pwcglobal.com">Nic Hobbs</a>
+      </assigned>
+    </task>
+
+    <task name="PropertyEditor Support">
+      <info>
+        <p>Add support for JavaBeans that include a <code>PropertyEditor</code>
+        class for conversion to and from the string representation used in an
+        HTML input field.  This support should operate in a manner consistent
+        with the way that standard JSP tags do in JSP 1.2.</p>
+      </info>
+    </task>
+
+    <task name="Event and Listener Model">
+      <info>
+        <p>Retrofit the Struts controller framework with supports for event
+        generation (and the corresponding registration of listeners) for all
+        interesting events created by the framework.  The list of interesting
+        events will undoubtedly be influenced by changes related to other
+        work items on this list (such as workflow processing and standard
+        validations), so work on this should be coordinated with those
+        changes.</p>
+        <p>
+        [STRUTS-DEV, Robert Leland, 10/10/2000]
+        [STRUTS-DEV, David Geary, 12/20/2000]
+        [STRUTS-USER, Ted Husted, 12/23/2000]
+        </p>
+      </info>
+    </task>
+
+    <task name="EJB Design Patterns">
+      <info>
+        <p>Begin adding design patterns and support for easy integration with
+        Enterprise JavaBeans (EJBs) for encapsulation of business logic and
+        application data.</p>
+      </info>
+      <assigned>
+        <a href="mailto:mschachter@hp.com">Mike Schachter</a>
+      </assigned>
+    </task>
+
+    <task name="HTML No-Cache Support">
+      <info>
+        <p>Improve the current Struts support for generating no-cache headers
+        to provide finer-grained, configurable control on a per-page basis.
+        </p>
+        <p>
+        [STRUTS-DEV, Hou Yunfeng, 10/07/2000]
+        [STRUTS-DEV, Matthias Kerkhoff, 11/18/2000]
+        </p>
+      </info>
+    </task>
+
+  </task-list>
+
+  <task-list name="Bean Tag Library [org.apache.struts.taglib.bean]"
+             href="BEAN">
+
+    <info>
+      <p>This tag library contains basic tags useful in manipulating JavaBeans
+      and their properties.  It includes support for getting and setting bean
+      properties using simple, nested, and subscripted accessor expressions.
+      </p>
+    </info>
+
+    <task name="XPath Support">
+      <info>
+        <p>Update all of the relevant tags to include property accessor support
+        using the syntax specified by the XPath standard (www.w3c.org).</p>
+      </info>
+      <assigned>
+        <a href="mailto:javabettin@yahoo.com">Dave Bettin</a>
+      </assigned>
+    </task>
+
+    <task name="XML DOM Support">
+      <info>
+        <p>Update all of the relevant tags to get and set attributes from a
+        Java object that implements the XML Document Object Model, as well as
+        from the current tree of JavaBean objects.  How the underlying data
+        object is stored should be transparent to page writers using these
+        tags.</p>
+      </info>
+      <assigned>
+        <a href="mailto:javabettin@yahoo.com">Dave Bettin</a>
+      </assigned>
+    </task>
+
+    <task name="XML DOM / JDBC RowSet Support">
+      <info>
+        <p>Update all of the relevant tags to get and set attributes from a
+        JDBC RowSet (or ResultSet) object, as well as from XML DOM objects and
+        the current tree of JavaBean objects.  How the underlying data object
+        is stored should be transparent to page writers using these tags.
+        </p>
+      </info>
+      <assigned>
+        <a href="mailto:javabettin@yahoo.com">Dave Bettin</a>
+      </assigned>
+    </task>
+
+    <task name="Formatting Support">
+      <info>
+        <p>Add the ability to use formatting patterns (suitably localized) for
+        presenting numbers, dates, times, timestamps, and so on via formatted
+        patterns.</p>
+        <p>
+        [STRUTS-DEV, Oleg Alexeev, 10/27/2000]
+        [STRUTS-USER, Ned Seagoon, 12/11/2000]
+        [STRUTS-DEV, Ned Seagoon, 12/13/2000]
+        [STRUTS-USER, Ned Seagoon, 01/04/2001]
+        </p>
+      </info>
+      <assigned>
+        <a href="mailto:javabettin@yahoo.com">Dave Bettin</a>
+      </assigned>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="HTML Tag Library [org.apache.struts.taglib.html]"
+             href="HTML">
+
+    <info>
+    <p>This tag library contains tags useful in preparing web applications that
+    use HTML forms as their primary mechanism for user data entry, as well as
+    support for internationalized and localized applications.</p>
+    </info>
+
+    <task name="Radio Button Groups">
+      <info>
+        <p>Add a new tag that supports generation of groups of radio buttons.
+        </p>
+        <p>
+        [STRUTS-DEV, Wellington Silva, 08/28/2000]
+        </p>
+      </info>
+    </task>
+
+    <task name="Improve Options Tag">
+      <info>
+        <p>Improve the mechanism by which you define values and corresponding
+        labels for <code>&lt;html:options&gt;</code>.</p>
+        <p>
+        [STRUTS-DEV, David Winterfeldt, 07/27/2000]
+        [STRUTS-DEV, David Winterfeldt, 08/02/2000]
+        [STRUTS-DEV, Andy Boyko, 11/15/2000]
+        [STRUTS-DEV, Andy Boyko, 12/07/2000]
+        </p>
+      </info>
+    </task>
+
+    <task name="Additional Attributes">
+      <info>
+        <p>Support additional HTML 4.0.1 attributes (such as "disabled",
+        "readonly", "wrap" on textarea)
+        where appropriate.</p>
+        <p>
+        [STRUTS-USER, , 08/23/2000]
+        </p>
+      </info>
+    </task>
+
+    <task name="Improved Iteration Support">
+      <info>
+        <p>Improve the ability to use the <code>&lt;logic:iterate&gt;</code>
+        tag over a collection, and generate a set of input fields for each
+        member of the collection (perhaps auto-generating a subscript?).
+        A significant use case is master-detail relationships (say, a
+        customer and their current orders) where you allow editing of any
+        and all fields.</p>
+        <p>
+        [STRUTS-USER, Lars, 12/06/2000]
+        [STRUTS-USER, Chandan Kulkarni, 12/26/2000]
+        </p>
+      </info>
+    </task>
+
+    <task name="Multi-Page Form Support">
+      <info>
+        <p>Create design patterns and improved internal support for forms that
+        span multiple pages.</p>
+      </info>
+      <assigned>
+        <a href="mailto:nic.hobbs@uk.pwcglobal.com">Nic Hobbs</a>
+      </assigned>
+    </task>
+
+  </task-list>
+
+  <task-list name="Logic Tag Library [org.apache.struts.taglib.logic]"
+             href="Logic">
+
+    <info>
+      <p>This tag library provides mechanisms to conditionally process
+      nested body content based on a variety of logical conditions.</p>
+    </info>
+
+    <task name="'Else' and 'Else If' Capability and Other Conditional Structures">
+      <info>
+        <p>Add "else" and "else if" constructs to the existing conditional
+        tags, in some reasonable format.</p>
+        <p>Add conditional tags that emulate the "case" or "switch"
+        capability of many programming languages.</p>
+        <p>NOTE: Pending the outcome of the JSPTL, this functionality will 
+        <strong>not</strong> be added to the Struts-Logic tags. However, a 
+        <a href="http://husted.com/struts/resources/logic-niallp.htm"><strong>contributor 
+         taglib</strong></a> is available.</p>
+      </info>
+      <assigned>
+        <a href="mailto:niall.pemberton@btInternet.com">Niall Pemberton</a>
+      </assigned>
+    </task>
+
+    <task name="Iterating Parallel Collections">
+      <info>
+        <p>Enhance <code>&lt;logic:iterate&gt;</code>, or provide a new
+        tag, to iterate over multiple collections in parallel.</p>
+        <p>
+        [STRUTS-DEV, Jeff R., 08/03/2000]
+        </p>
+      </info>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="WML Tag Library [org.apache.struts.taglib.wml]"
+             href="WML">
+
+    <info>
+    <p>This tag library will contain tags useful in preparing web applications
+    similar to those supported by the HTML tag library, but render output that
+    is well-formed XML in accordance with WML specifications.</p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="XFORMS Tag Library [org.apache.struts.taglib.xforms]"
+             href="xforms">
+
+    <info>
+      <p>This potential new tag library provides access to facilities in the
+      emerging XForms standards.</p>
+    </info>
+
+    <task name="Generalized Form Handling">
+      <info>
+        <p>Consider how to support more generalized definitions of forms and
+        their fields, perhaps based on emerging XForms standards.</p>
+      </info>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="XHTML Tag Library [org.apache.struts.taglib.xhtml]"
+             href="XHTML">
+
+    <info>
+    <p>This tag library will contain tags useful in preparing web applications
+    similar to those supported by the HTML tag library, but render output that
+    is well-formed XML in accordance with the XHTML 1.0 specification.</p>
+    </info>
+
+  </task-list>
+
+
+  <task-list name="Tools Support [org.apache.struts.tools]"
+             href="Tools">
+
+    <info>
+      <p>This package contains code generators and other tools that
+      facilitate the creation of Struts-based applications.  Further
+      subdivision into specialized packages should be performed as
+      appropriate.</p>
+    </info>
+
+    <task name="XML --&gt; ActionForm Code Generator">
+      <info>
+        <p>Create a tool that takes an XML-based description of the
+        properties of the form bean, and automatically generates
+        the corresponding Java class.</p>
+        <p><a href="http://husted.com/struts/resources/codemaker.htm"><strong>A 
+        contributor extension is now available.</strong></a></p>
+        <p>
+        [STRUTS-DEV, Mark Wutka, 06/01/2000 and 06/16/2000]
+        </p>
+      </info>
+      <assigned>
+        <a href="ravi@sengen.com">Ravindran Ramaiah</a>
+      </assigned>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="Utility Classes [org.apache.struts.util]" href="Util">
+
+    <info>
+      <p>This package contains a variety of utility classes useful within
+      Struts as well as in stand-alone applications.</p>
+    </info>
+
+    <task name="XmlMessageResources">
+      <info>
+        <p>Implementation of <code>MessageResources</code> and
+        <code>MessageResourcesFactory</code> that loads message keys
+        and strings from one or more XML resources or files.</p>
+        <p>
+        [STRUTS-DEV, Scott Sayles, 01/07/2000]
+        </p>
+      </info>
+    </task>
+
+    <task name="Enhanced Collections Support">
+      <info>
+        <p>Improve support in <code>BeanUtils</code>,
+        <code>ConvertUtils</code>, and <code>PropertyUtils</code> for property
+        values that implement <code>Collection</code>, <code>List</code>, or
+        <code>Set</code>, treating them in a manner similar to the way that
+        indexed or array-valued properties are handled.</p>
+        <p>
+        [Bugzilla #640]
+        </p>
+      </info>
+    </task>
+  </task-list>
+
+  <task-list name="Unit Test Suites" href="UnitTests">
+
+    <info>
+      <p>Unit test components compatible with the JUnit and Cactus testing
+      frameworks, to test and validate internal APIs of the Struts framework.
+      Volunteers will typically agree to develop tests for an entire package
+      within the Java source code of Struts.
+      </p>
+    </info>
+
+    <task name="Action">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.action</code> package.</p>
+      </info>
+      <assigned>
+        <a href="mailto:struts-test@freetocreate.org">Rob Leland</a>
+      </assigned>
+    </task>
+
+    <task name="Actions">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.actions</code> package.</p>
+      </info>
+    </task>
+
+    <task name="Taglib.Bean">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.taglib.bean</code> package.</p>
+      </info>
+    </task>
+
+    <task name="Taglib.Html">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.taglib.html</code> package.</p>
+      </info>
+    </task>
+
+    <task name="Taglib.Logic">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.taglib.logic</code> package.</p>
+      </info>
+    </task>
+
+    <task name="Taglib.Template">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.taglib.template</code> package.</p>
+      </info>
+    </task>
+
+    <task name="Upload">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.taglib.upload</code> package.</p>
+      </info>
+    </task>
+
+    <task name="Util">
+      <info>
+        <p>Unit tests for the <code>org.apache.struts.util</code> package.</p>
+      </info>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="Additional Possibilities" href="Additional">
+
+    <info>
+      <p>This section is a catch-all for additional areas of functionality
+      to be investigated for inclusion into Struts.</p>
+    </info>
+
+    <task name="Coarse Grain Components">
+      <info>
+        [STRUTS-DEV, Cedric Dumoulin, 10/03/2000]
+      </info>
+    </task>
+
+    <task name="Multidimensional Properties">
+      <info>
+        [STRUTS-DEV, Eric, 11/07/2000]
+      </info>
+    </task>
+
+    <task name="Portal Components">
+      <info>
+        [STRUTS-DEV, Phil Grimm, 11/22/2000]
+      </info>
+      <assigned>
+        <a href="mailto:husted@apache.org">Ted Husted</a>
+      </assigned>
+    </task>
+
+    <task name="Storefront Example App">
+      <info>
+        [STRUTS-DEV, David D'Orto, 12/11/2000]
+      </info>
+    </task>
+
+  </task-list>
+
+
+  <task-list name="Contributors Area" href="Contrib">
+
+    <info>
+      <p>A portion of the Struts web site, and file system, where individually
+      contributed add-ons for Struts can be hosted and downloaded.</p>      
+    </info>
+    
+    <task name="Proposal">
+     <info>
+       <p>Detailed proposal with implementation plan.</p>
+       <p> [STRUTS-USER, Ned Seagoon, 12/22/2000]</p>
+     </info>
+     <assigned>
+      <a href="mailto:husted@apache.org">Ted Husted</a>
+     </assigned>
+    </task>
+
+  </task-list>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/proposals/workflow.xml b/build-legacy/core/xdocs/proposals/workflow.xml
new file mode 100644
index 0000000..c9f2913
--- /dev/null
+++ b/build-legacy/core/xdocs/proposals/workflow.xml
@@ -0,0 +1,397 @@
+<?xml version="1.0"?>
+<document url="./proposal-workflow.xml">
+
+  <properties>
+    <title>Proposal - Workflow Management System</title>
+  </properties>
+
+  <body>
+
+    <section name="Recent Developments">
+
+        <p>
+            Work on this initiative has stalled.
+            It is recommended that interested parties look to the
+            <a href="http://jakarta.apache.org/commons/jelly/index.html">Commons Jelly</a> product.
+            A way to persist the workflow state between sessions is needed, but Jelly otherwise fills the needs identified by this proposal.
+        </p>
+
+    </section>
+
+  <section name="Background and Goals">
+
+  <p>Struts 1.0 has become an increasingly popular platform for constructing
+  web applications based on a Model-View-Controller type design pattern (also
+  known as the <em>Front Controller</em> pattern.  It has achieved this
+  popularity for many reasons, but key among them have been:</p>
+  <ul>
+  <li>The simplicity of the basic organizational principles (once you
+      understand them)</li>
+  <li>The principle of <em>logical naming</em> to assist in isolating
+      the view layer and the model layer, so that changes in one do not
+      have to impact the other</li>
+  <li>A rich set of tools to assist in creating pages with dynamic content
+      exposed by the model layer through JavaBeans</li>
+  </ul>
+
+  <p>One consequence of the original Struts design, however, is that the
+  framework does not provide much assistance in organizing business
+  transactions that require more than one interaction with the user (i.e.
+  they span more than one JSP page and/or Action).  Applications are left
+  to manage navigation issues, as well as deal with ActionForms whose
+  logical contents crosses page boundaries.</p>
+
+  <p>The original Struts design materially assists page designers in creating
+  dynamic pages, while protecting them from having to be very concerned with
+  the business logic -- other than the names of the JavaBeans used to
+  communicate model layer data to the presentation layer.  However, Struts 1.0
+  still requires a Java developer to be involved on the business logic side
+  (even if all of the functional logic is already available in Java classes)
+  in order to create the Action classes.</p>
+
+  <p>The purpose of this <em>Workflow Management System</em> proposal is to
+     address some of these consequences.  In particular, it intends to address
+     the following set of goals:</p>
+  <ul>
+  <li>Create a means where multiple-user-interaction business processes can be
+      configured (scripted), including support for conditional processing
+      and branching.</li>
+  <li>Support scripting elements that lets business application experts,
+      who are not necessarily Java developers, can integrate pre-existing
+      business functionality that is available as public methods on
+      arbitrary Java classes.</li>
+  <li>Assist page designers in creating the user interface elements that
+      correspond to navigation links within, or between, work flows.</li>
+  </ul>
+
+  </section>
+
+
+  <section name="Use Cases and Examples">
+
+    <p>To give a flavor of what scripted workflow activities might look like,
+    it is useful to consider some possible use case scenarios.  The
+    syntax that is shown for the examples should be considered as
+    illustrative of what should be possible, rather than normative.
+    No rigorous attempt has been made to guarantee consistency
+    between (or even within) these examples.</p>
+
+    <subsection name="Application Logon">
+
+      <p>The example application included with Struts (like many other
+      web applications) uses application-managed security, including
+      a logon form.  Consider that a business logic bean might be available
+      (in some scope under key <code>authenticator</code>)
+      that knows how to authenticate users given a username and password.
+      It could be utilized to script application logon like this:</p>
+
+<pre>
+&lt;activity id="Application Logon"&gt;
+
+  &lt;-- Display the logon form (web framework independent) --&gt;
+  &lt;web:forward id="display" page="/logon.jsp"/&gt;
+
+  &lt;-- Authenticate the username and password, returning a Principal
+      if accepted, or null if not --&gt;
+  &lt;web:set  name="username" value="$parameter:username"/&gt;
+  &lt;web:set  name="password" value="$parameter:password"/&gt;
+  &lt;core:invoke bean="authenticator" method="authenticate"&gt;
+    &lt;core:param type="java.lang.String" value="$username"/&gt;
+    &lt;core:param type="java.lang.String" value="$password"/&gt;
+    &lt;core:return name="principal"/&gt;
+  &lt;/core:invoke&gt;
+
+  &lt;-- If no Principal was returned, branch back to the logon form --&gt;
+  &lt;core:if expr="$principal == null"&gt;
+    &lt;web:set name="error" value="$messages.lookup('invalid.logon')"/&gt;
+    &lt;core:branch idref="display"/&gt;
+  &lt;/core:if&gt;
+
+  &lt;-- Exit to the "Main Menu" workflow --&gt;
+  &lt;core:goto name="Main Menu"/&gt;
+
+&lt;/activity&gt;
+</pre>
+
+    </subsection>
+
+
+    <subsection name="Simple Multi-Page Wizard">
+
+      <p>Many complex data entry operations can be simplified (from the
+      user's point of view) by dividing them up into a series of simple
+      dialog pages that ask a few (often one) question that leads ultimately
+      to a completed set of information required to process a request.
+      In many cases, each page of the interaction will have navigation
+      controls so that the user can short cut to immediate execution,
+      or cancel the entire interaction.  Such an interaction might be
+      modelled like this:</p>
+
+<pre>
+&lt;activity id="Simple Wizard Application"&gt;
+
+  &lt;!-- Display the first page of the iteration --&gt;
+  &lt;!-- (Using Struts-specific logical-to-physical mapping) --&gt;
+  &lt;struts:forward id="page1" name="Simple Wizard Page 1"&gt;
+
+  &lt;!-- Process navigation input from the first page --&gt;
+  &lt;!-- (Can do something much like this framework-independently too) --&gt;
+  &lt;struts:navigate&gt;
+    &lt;struts:branch control="CANCEL" idref="cancel"/&gt;
+    &lt;struts:branch control="FINISH" idref="finish"/&gt;
+    &lt;struts:branch control="NEXT"   idref="page2"/&gt;
+  &lt;/struts:navigate&gt;
+
+  &lt;!-- Display the second page of the iteration --&gt;
+  &lt;struts:forward id="page2" name="Simple Wizard Page 2"&gt;
+
+  &lt;!-- Process navigation input from the second page --&gt;
+  &lt;struts:navigate&gt;
+    &lt;struts:branch control="CANCEL" idref="cancel"/&gt;
+    &lt;struts:branch control="FINISH" idref="finish"/&gt;
+    &lt;struts:branch control="NEXT"   idref="page3"/&gt;
+    &lt;struts:branch control="PREV"   idref="page1"/&gt;
+  &lt;/struts:navigate&gt;
+
+  &lt;!-- Display the third page of the iteration --&gt;
+  &lt;struts:forward id="page3" name="Simple Wizard Page 3"&gt;
+
+  &lt;!-- Process navigation input from the third page --&gt;
+  &lt;struts:navigate&gt;
+    &lt;struts:branch control="CANCEL" idref="cancel"/&gt;
+    &lt;struts:branch control="FINISH" idref="finish"/&gt;
+    &lt;struts:branch control="PREV"   idref="page2"/&gt;
+  &lt;/struts:navigate&gt;
+
+  &lt;!-- Process the FINISH navigation control as appropriate --&gt;
+  &lt;xxx:yyy id="finish" .../&gt;
+  &lt;core:goto name="Main Menu"/&gt;
+
+  &lt;!-- Process the CANCEL navigation control as appropriate --&gt;
+  &lt;xxx:yyy id="cancel" .../&gt;
+  &lt;core:goto name="Main Menu"/&gt;
+
+&lt;/activity&gt;
+</pre>
+
+
+      <p>Not illustrated above, but also interesting to explore, would be
+      the situation where choices on one page affect whether some pages
+      in the overall flow might be skipped.</p>
+
+    </subsection>
+
+
+  </section>
+
+
+  <section name="User Visible Features">
+
+
+    <p>Workflow system capabilities will be exposed to applications through
+    Java APIs that represent both the static description of particular
+    activities and the dynamic current state of a computation.  Object
+    factory and pluggable implementation patterns shall be used where
+    appropriate to maximize the generality and flexibility of the system.</p>
+
+
+    <subsection name="Workflow Management System Implementation Objects">
+
+      <p>The following classes represent the primary components of the
+      workflow management system:</p>
+
+      <p><strong>Registry</strong> - Collection into which multiple
+      <em>Process</em> and <em>Activity</em> static descriptions can be
+      stored and retrieved by String-valued keys.</p>
+
+      <p><strong>Process</strong> - The static description of a tree of
+      business activities that are executed in a nested fashion, often by
+      separate individuals (or application systems).</p>
+
+      <p><strong>Activity</strong> - The static description of a sequence
+      of Steps that are generally executed by a single individual (or
+      application system), within a reasonably short period of time.</p>
+
+      <p><strong>Step</strong> - The static description of an individual
+      task to be performed as a discrete, indivisible, unit.  Steps can
+      also be nested inside other steps, to provide for looping and
+      conditional processing.  A rich set of built-in Step implementations
+      shall be provided (including powerful capabilities such as the
+      execution of an arbitrary method on an arbitrary Java object), and
+      mechanisms to extend the set of supported Step implementations
+      allows arbitrary extensibility.</p>
+
+      <p><strong>Context</strong> - The dynamic state of a computation
+      through an <em>Activity</em> (or a set of nested <em>Activities</em>),
+      including provision of storage space for JavaBeans produced and
+      consumed by other Steps.  Contexts keep track of the current Step
+      being executed, so that activity processing can be suspended and
+      resumed later.</p>
+
+      <p><strong>Scope</strong> - A <code>Map</code> into which
+      arbitrary Java objects can stored and retrieved by String-valued keys.
+      Context support a number of individual Scopes, each of which can be
+      plugged in from application logic, to provide integration into
+      existing application functionality.  For example, in a web application
+      implementation, Scopes will generally be mapped directly to request
+      attributes, session attributes, and servlet context attributes as
+      provided by the Servlet API.</p>
+
+    </subsection>
+
+
+    <subsection name="Built-In Steps">
+
+      <p>A rich variety of built-in <em>Step</em> implementations (and
+      corresponding XML elements in specified namespaces) will be provided
+      as part of the basic workflow engine, and as part of the associated
+      Struts integration of this engine.</p>
+
+      <p><strong>Bean Interaction</strong> - The ability to get and set
+      JavaBeans in arbitrary Scopes (mapped via the Context to real collections
+      of objects).</p>
+
+      <p><strong>Control Flow</strong> - Conditionals and looping, where
+      control flow Steps can contain nested sets of Steps to an arbitrary
+      degree.</p>
+
+      <p><strong>Method Execution</strong> - Execute arbitrary public methods
+      of beans stored in some Scope, passing specified arguments (expressions
+      or bean references) and returning the method's result (if any) to a
+      named bean in some Scope.  To maximize usefulness of the workflow
+      system in composing applications, <strong>no</strong> restrictions
+      should be placed on the object types these Steps can interact with.</p>
+
+      <p><strong>Activity Management</strong> - GOTO a named Activity
+      (exiting the current one), CALL a named Activity (resuming the current
+      one when the called Activity returns, RETURN from a called Activity,
+      EXIT the Activity system.</p>
+
+      <p><strong>User Interaction</strong> - Suspend workflow execution to
+      interact with the user in some application specific way.  For example,
+      a web application would display a page and wait for input to be
+      submitted before resuming the workflow.</p>
+
+      <p><strong>Specialized Processing</strong> - Prebuilt Steps for common
+      processing functions such as XSLT transformations, performing
+      arbitrary SQL queries, sending mail, and so on.</p>
+
+    </subsection>
+
+
+  </section>
+
+
+  <section name="Implementation Notes">
+
+  <p>The implementation of this proposal will be divided into three major
+  development layers:</p>
+  <ul>
+  <li>Core workflow management system capabilities and built in Step
+      implementations that are independent of application environment.
+      [Code in jakarta-commons]</li>
+  <li>Specialized implementation of workflow management system components
+      that integrate with the Servlet API in a manner that is independent
+      of any specific application framework.  [Code in jakarta-commons]</li>
+  <li>Specialized implementation of workflow management system components
+      that is tightly integrated with Struts's internal architecture and
+      custom tag libraries.  [Code in jakarta-struts]</li>
+  </ul>
+
+  <p>The workflow management system will support the general concept of
+  <em>Scopes</em> in which beans can be stashed, with pluggable
+  implementations for integration into different working environments.
+  None of the APIs in the workflow engine itself will have any reference
+  to the web layer (i.e. no imports of <code>javax.servlet.*</code>).</p>
+
+  <p>Suitable object factory and pluggability APIs will be included
+  to guarantee extensibility of the basic framework.
+  </p>
+
+  <p>Scripting of business transactions will be codified in XML documents
+  that conform to an appropriate DTD and/or schema.  The XML technology
+  that is used will facilitate extensible definitions of <em>Steps</em>
+  and other components, in both the XML description of these components and
+  in the set of Java objects that implements them.
+  </p>
+
+    
+  <p>When designing the detailed syntax of the XML representation
+  of Steps, consider whether it is feasible for advanced development
+  tools to "compile" activities into individual classes to optimize
+  overall performance.
+  </p>
+  
+  <p>When designing the detailed syntax of the XML representation
+  of Steps, consideration should be given to emulating the syntax
+  of other XML applications that are similar in spirit or detail
+  to the concepts of scripting a business transaction.  Useful
+  models to consider include:
+  </p>
+    <ul>
+    <li><a href="http://www.w3.org/TR/xslt">XSL Transformations (XSLT)</a>
+        - Includes control flow mechanisms that are becoming widely
+        known and understood, which could be mimicked.</li>
+    <li><a href="http://jakarta.apache.org/taglibs/jsptl-doc/intro.html">
+        JSP Standard Tag Library (Early Access)</a> - The design goals for
+        many of the JSP custom tags in this library (produced by the
+        JSR-052 expert group under the Java Community Process) are similar
+        enough to provide a useful model for conditionals, looping, and
+        interaction with objects in arbitrary scopes.</li>
+    </ul>
+
+    <p>To maximize the usefulness of built-in actions, an expression
+    language that knows how to manipulate objects in the Scopes associated
+    with the current Context will need to be supported.  Useful models to
+    consider include:</p>
+    <ul>
+    <li><a href="http://www.w3.org/TR/xpath">XML Path Language (XPath)</a>
+        - Will be familiar to XML-oriented application developers because
+        it is used throughout the suite of XML specifications.</li>
+    <li>JavaScript like expression languages - Will be familiar to page
+        developers (as well as Struts developers familiar with the
+        nested and indexed property accessor syntax of many Struts tags).</li>
+    </ul>
+
+    <p>From the workflow script developer's point of view, XML namespaces
+    will be used to introduce extended sets of Step implementations.  There
+    will need to be mechanisms to map a particular namespace to a set of
+    legal XML elements (within that namespace) and corresponding Java
+    classes that provide the functionality for those Steps.</p>
+
+  <p>The web layer integration will include a mechanism to map scopes (from
+  the workflow perspective) into the standard <em>request</em>,
+  <em>session</em>, and <em>application</em> scopes of the web layer.
+  Thus, workflow scripts will be able to place beans in appropriate
+  scopes such that JSP pages can directly pull that data into the presentation,
+  much as Struts Actions (and the business logic classes that are called by
+  those Actions) can place beans there in a Struts 1.0 based application.
+  Utilizing these capabilities, application developers will be able to
+  "script" the business logic requirements of many applications, by
+  combining functional logic already available as methods on business
+  logic beans, without having to involve Java programmers to create new
+  Actions (or otherwise synthesize business logic out of the constituent
+  pieces).</p>
+
+  <p>Components in the web layer integration may import APIs from the
+  Servlet and JSP specifications, but not from any application specific
+  framework.  Framework-specific integration will occur on top of the
+  generic web layer integration.</p>
+
+  <p>In addition, the Struts integration will include a small custom tag
+  library will be included, so that page
+  developers can easily create navigational links and controls.  Examples
+  of such controls include links to the "next", "previous", and "finish"
+  pages of a wizard dialog, a "cancel" button to exit a workflow early, or
+  an "invoke" button to invoke a new workflow as a subroutine, and then
+  return to the current step of the original workflow.  Utilizing these
+  capabilities, page developers can create the individual visible pieces
+  of a work flow dialog, without having to be involved in navigational
+  complexities.</p>
+
+  </section>
+
+
+  </body>
+
+</document>
diff --git a/build-legacy/core/xdocs/releases.xml b/build-legacy/core/xdocs/releases.xml
new file mode 100644
index 0000000..945fb8e
--- /dev/null
+++ b/build-legacy/core/xdocs/releases.xml
@@ -0,0 +1,277 @@
+<?xml version="1.0"?>
+<document url="./releases.xml">
+
+<!--
+// ======================================================================== 78
+-->
+
+<properties>
+    <title>Release Guidelines - The Apache Struts Web Application Framework</title>
+</properties>
+
+<body>
+    <section href="status" name="Release Guidelines">
+
+    <p>
+    This document describes the Struts <a href="#Releases">release process</a> and our <a href="#Coding">coding
+    conventions</a>. Both stable and development releases are <a href="acquiring.html">available for download</a>.
+    </p>
+
+    </section>
+
+    <section href="Releases" name="Release Guidelines">
+
+        <p>
+            A <a href="http://jakarta.apache.org/commons/versioning.html">point release</a>
+            should be made before and after any product change that is not a "fully-compatible change"
+            (see link). This includes moving a dependency from an internal package to an external product,
+            including products distributed through the Jakarta Commons.
+            We should place any fully-compatible changes in the hands of the community
+            before starting on a change that is only "interface" or "external-interface" compatible.
+        </p>
+        <p>
+            A fully-compatible point release does not always need a "preview" beta or milestone release.
+            If appropriate, a Release Candidate can be cut, uploaded to the Release Manager's home directory
+            on svn.apache.org (~/public_html), and voted to be released to the general public from there.
+        </p>
+
+        <p>
+            Any release should follow the same general process used by the Jakarta Commons
+            and the Apache HTTP Server project.
+        </p>
+
+        <ul>
+            <li>
+                 <a href="http://jakarta.apache.org/commons/releases/">Releasing Common Components</a>
+            </li>
+            <li>
+                <a href="http://wiki.apache.org/incubator/SigningReleases">Signing a release version</a>
+                <ul>
+                <li>
+                    <small>The MD5 tool is installed on daedalus, and you can create the digests for Struts releases
+                        there.</small>
+                </li>
+                </ul>
+            </li>
+            <li>
+                <a href="http://httpd.apache.org/dev/release.html">Apache HTTPD Server Release Guidelines</a>
+            </li>
+        </ul>
+
+        <p>
+            Additional remarks:
+        </p>
+
+        <ul>
+            <li>
+                The release process can seem daunting when you review it for the first time.
+                But, essentially, it breaks down into three phases of just a few steps each:
+                <ul>
+                    <li>Building - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build
+                        (using the release target).</li>
+                    <li>Testing - JUnit, Cactus, web apps (for all "supported" containers). </li>
+                    <li>Distributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site,
+                        announce.</li>
+                </ul>
+            </li>
+            <li>
+                Our dependencies on external JARs (including Commons JARs) should
+                be in line with our own release status.
+                Our nightly build can be dependant on another nightly build.
+                Our beta can be dependant on another beta,
+                but should avoid a dependance on a nightly build.
+                Our release candidate can have a dependance on another RC,
+                but should not have a dependance on a beta (and certainly <strong>not</strong> a nightly build).
+                Our final release can only have dependencies on other final releases.
+            </li>
+            <li>
+                Use your own discretion as to detail needed by the Release Notes.
+                A high-level description of the changes is more important than providing uninterpreted detail.
+                At a minimum, new features and deprecations should be summarized,
+                since these are commonly asked questions.
+                Ideally, the release notes should be maintained continuously for the nightly build
+                so that we do not need to quickly assembled them on the eve of a Release.
+            </li>
+            <li>
+                Test building the distribution under prior version of J2SE, if possible,
+                to ensure that we are still backwardly-compatible.
+                But, our Release distribution should be built using the <strong>latest release of J2SE</strong>,
+                to take advantage of all available compiler enhancements.
+            </li>
+            <li>
+                Before building the release, run the JUnit and Cactus tests using the same
+                configuration used that will be used to build the Release distribution.
+            </li>
+            <li>
+                There is a "release" target in the buildfile that will zip and tar the releases.
+                Before uploading the release, extract the sample web applications and deploy the WARs under
+                each of the "supported" containers.
+                Play test each application under each container to be sure they operate nominally.
+            </li>
+            <li>
+                Be sure to copy the pmc@jakarta.apache.org list on any release announcement.
+            </li>
+            <li>
+                Remember to update the <a href="status.html">Status section of the Roadmap page</a> 
+                once a release is available. 
+            </li>
+            <li>
+                By the way, the nightly builds are being created on a machine of Craig McClanahan's.
+                If there are problems with a nightly build that seem infrastructure related,
+                Craig is the one to contact.
+            </li>
+        </ul>
+
+    </section>
+
+
+<section href="Coding" name="Coding Conventions and Guidelines">
+
+    <p>
+    Source code and documentation contributed to the Struts repositories
+    should observe the:
+    </p>
+
+    <ul>
+
+        <li>
+          <a href="http://jakarta.apache.org/site/source.html">Jakarta project
+          guidelines</a>,
+        </li>
+
+        <li>
+          <a href="http://www.ambysoft.com/elementsJavaStyle.html">Elements of
+          Java Style</a>, and
+        </li>
+
+        <li>
+          <a href="http://java.sun.com/j2se/javadoc/writingdoccomments/">How to
+          write Doc Comments</a>
+        </li>
+
+    </ul>
+
+    <p>
+    as core references regarding the formatting of code and documentation.
+    </p>
+
+    <p>
+    <strong>Clarifications</strong>
+    </p>
+
+    <ul>
+
+        <li>
+        First, "Observe the style of the original".
+        Resist the temptation to make stylistic changes for their own sake.
+        But, if you must reformat code, commit style changes separately from
+        code changes.
+        Either change the style, commit, and then change the code, or vice-
+        versa.
+        </li>
+
+        <li>
+        Set editors to replace tabs with spaces, and do not trim trailing
+        spaces.
+        </li>
+
+        <li>
+        Specify imported classes (do not use <code>.*</code>).
+        </li>
+
+        <li>
+        Write all if/else statements as full blocks with each clause within braces,
+        unless the entire statement fits on the same line.
+        </li>
+
+        <li>
+        Use <code>:FIXME:</code> and <code>:TODO:</code> tokens to mark follow up
+        notes in code.
+        You may also include your Apache username and the date.
+        <code>:FIXME: we need to do this sometime (husted 2002-11-14)</code>
+        </li>
+
+        <li>
+        Use <code>@since</code> to document changes between Struts versions,
+        as in <code>@since Struts 1.1</code>.
+        </li>
+
+        <li>
+        Wrap lines of code and JavaDoc at column 78.
+        You can include a "comment rule" in the source to help with this.<br />
+        <small>
+        // ------------------------------------------------------------------------ 78
+        </small>
+        </li>
+
+        <li>
+        Please do your best to provide high-quality JavaDocs for all source code
+        elements.
+        Package overviews (aka "Developer Guides") are also encouraged.
+        </li>
+
+        <li>
+        When working on a bugfix, please first write a
+        <a href="http://www.junit.org">JUnit</a> test that proves the bug exists,
+        and then use the test to prove  the bug is fixed. =:0)
+        </li>
+
+        <li>
+        When working on an enhancement, please feel free to use test-driven design
+        and write the test first &lt;head-slap/>.
+        For more about TDD, see the
+        <a href="http://sourceforge.net/projects/mockobjects">MockObjects project
+        </a>.
+        </li>
+
+        <li>
+        As files are updated from year to year, the copyright on each file should
+        be extended to include the current year.
+        You do not need to change the copyright year unless you change the file.
+        Every source file should include the current Apache License and copyright.
+        </li>
+
+        <li>
+        Provide high-level API compatibility for any changes made within the same
+        major release series (#.x).
+        Changes which adversely affect compatibility should be slotted for the
+        next major release series (++#.x).
+        </li>
+
+        <li>
+        Our favorite books about programming are
+        <a href="http://www.amazon.com/exec/obidos/ISBN=0201633612/hitchhikeguidetoA/">
+        Design Patterns</a> and
+        <a href="http://www.amazon.com/exec/obidos/ISBN=0201485672/hitchhikeguidetoA/">
+        Refactoring</a>.
+        </li>
+
+        <li>
+        Our favorite book about open source development is the
+        <a href="http://www.amazon.com/exec/obidos/ISBN=1565927249/hitchhikeguidetoA/">
+        The Cathedral and the Bazaar</a>.
+        </li>
+
+        <li>
+        Our favorite science fiction author is
+        <a href="http://www.nitrosyncretic.com/rah/">Robert Heinlein</a>.
+        <a href="http://www.tuxedo.org/~esr/jargon/html/entry/TANSTAAFL.html">
+        TANSTAAFL</a>.<br />
+        (Except on Friday, when we favor
+        <a href="http://carbon.cudenver.edu/~mstilman/zaphod/">Douglas
+        Adams</a>.
+        <a href="http://news.bbc.co.uk/1/hi/uk/1326657.stm">
+        SLATFATF</a>.)
+        </li>
+
+    </ul>
+
+</section>
+
+<section>
+    <p class="right">
+    Next: <a href="news/index.html">News and Status</a>
+    </p>
+</section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/status.xml b/build-legacy/core/xdocs/status.xml
new file mode 100644
index 0000000..8e16f69
--- /dev/null
+++ b/build-legacy/core/xdocs/status.xml
@@ -0,0 +1,483 @@
+<?xml version="1.0"?>
+<document url="./status.xml">
+
+<!--
+// ======================================================================== 78
+-->
+
+<properties>
+    <title>Status - The Apache Struts Web Application Framework</title>
+</properties>
+
+<body>
+    <section name="Status" href="status">
+
+    <p>
+        The <strong>stable production release</strong> is
+        <a href="http://www.apache.org/dist/jakarta/struts/binaries/">Struts 1.1.0</a> (29 June 2003).
+    </p>
+
+    <hr/>
+
+    <ul>
+    <li>
+      See the <a href="../status.html">Development Roadmap</a> for an overview of future plans.
+    </li>
+    <li>
+        See the <a href="http://jakarta.apache.org/site/bugs.html">Apache Bug Database</a> for outstanding issues and
+        enhancement requests.
+      </li>
+    <li>
+        See the <a href="http://jakarta.apache.org/builds/jakarta-struts/nightly/">Struts Nightly Build</a> for the
+        latest development distribution.
+    </li>
+    <li>
+        See the <a href="http://jakarta.apache.org/site/mail.html">Struts-Dev list</a> for current development
+        communications.
+    </li>
+    <li>
+        See the <a href="http://cvs.apache.org/viewcvs/jakarta-struts/">Struts CVS</a> for the current development
+        codebase.
+      </li>
+    <li>
+       See the <a href="../releases.html">Release Guides</a> for our release process and coding conventions.
+    </li>
+    </ul>
+
+</section>
+
+<section href="roadmap" name="Development Roadmap">
+
+    <p class="version">
+    $Id$
+    </p>
+
+    <p>
+    This document outlines some of changes we expect to
+    see in future releases of Struts.
+    </p>
+
+    <p>
+    This document is provided for discussion purposes only.
+    All releases and changes to the codebase are subject to
+    <a href="http://jakarta.apache.org/site/decisions.html">a vote</a> of the
+    <a href="volunteers.html#committers">Struts Committers</a>.
+    </p>
+
+    </section>
+
+    <section href="Bugzilla" name="Bugzilla Queries">
+
+        <p>
+            The Struts development teams uses the <a href="http://jakarta.apache.org/site/bugs.html">Apache Bug Database</a> (Bugzilla)
+            to manage problem reports and enhancement requests.
+            For your convenience, here are some common Bugzilla queries:
+        </p>
+
+        <ul>
+            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;order=%27Importance%27">Open reports</a></li>
+            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;bug_severity=Blocker&amp;bug_severity=Critical&amp;bug_severity=Major&amp;bug_severity=Normal&amp;bug_severity=Minor&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=%27Importance%27">Open problem reports</a>
+                <ul>
+                <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;bug_severity=Blocker&amp;bug_severity=Critical&amp;bug_severity=Major&amp;order=%27Importance%27">major problem reports</a></li>
+                <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;bug_severity=Blocker&amp;bug_severity=Normal&amp;bug_severity=Minor&amp;order=%27Importance%27">minor problem reports</a></li>
+                </ul>
+                </li>
+            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;product=Struts&amp;bug_severity=Enhancement&amp;order=%27Importance%27">Open enhancement reports</a></li>
+            <li><a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=LATER&amp;resolution=REMIND&amp;product=Struts&amp;order=%27Importance%27">Reports to be handled "LATER"</a></li>
+        </ul>
+
+
+    </section>
+
+<section href="Struts_1_x" name="Struts 1.x">
+
+    <p>
+        The platform requirements throughout the Struts 1.x series will remain the same (Servlet 2.2 / JSP 1.1).
+        Though, later platforms may be supported as an option.
+    </p>
+    <p>
+        Releases in the 1.x series will focus on refactoring of existing functionality, with a
+        continued emphasis on backward compatibility, as were seen in Struts 1.1.
+        However, we expect there to releases to be incremental throughout the rest of the
+        1.x series, so that improvements and fixes become available to production teams every few weeks.
+    </p>
+
+    <p>
+        Any feature that can be implemented under Servlet 2.2/JSP 1.1 may be considered for the Struts 1.x series.
+        This may include, but is not limited to, better support for alternate view technologies (like XLST),
+        integrated unit testing, integrated support for HTTP/HTTPS mode switching, better workflow handling,
+        support for alternative action types (e.g. BSF actions), a chainable request processor, support for an Action
+        context, and so forth.
+    </p>
+
+    <p>
+        Features most likely to be considered are those that have already been implemented as
+        third-party extensions and are in active use by the Struts Community, such as
+        those distributed through the
+        <a href="http://sourceforge.net/projects/struts">Struts SourceForge</a> site.
+    </p>
+
+    <p>
+        Throughout the 1.x series, there will be a continued emphasis on expanding unit test coverage for the
+        framework.
+        Bug reports should include a failing test case when possible.
+        Proposals for new features should include a working test suite.
+        (Creating features through Test Driven Development is strongly encouraged.)
+    </p>
+
+    <p>
+        Enhancement requests are logged in Bugzilla they are suggested.
+        <strong>The listing of an enhancement in Bugzilla does not imply that is being "planned"</strong>, merely that some
+        member of the community has suggested it, and the idea hasn't been ruled out (yet).
+    </p>
+
+    <p>
+        Future release milestones are provided for enhancements which are being actively planned or developed
+        but may not be ready for the very next release.
+        If a report has not been tagged for a specific milestone by a working developer, then <strong>it may never be
+        resolved</strong>.
+        When developers (including non-Committers) are actually working on an enhancement, they should re-tag it for a
+        specific release milestone, such as "1.2.1" or "1.2.2".
+    </p>
+
+    <p>
+        If an enhancement has not been tagged for a specific target, feel free to start working on it yourself.
+        Many of our best features have been contributed by developers, just like you.
+        If you would like to announce your active interest in an enhancement, please post a note on the ticket, and tag
+        it to an appropriate release milestone.
+    </p>
+
+    </section>
+
+    <section href="Struts_1_x_whiteboard" name="Struts 1.x Whiteboard">
+
+        <p>
+            These are some general ideas we have about what may happen in the Struts 1.x series.
+            This is a <strong>whiteboard</strong> and everything here is <strong>subject to change</strong>.
+        </p>
+
+        <ul>
+
+            <li>Struts 1.0.0 (complete) -
+            Major refactoring of Struts internals to provide support for modules and a new "config" object series.
+            Bundles Struts Tiles and Struts Validator into main distribution.
+            The initial release of Struts EL is provided as an optional package.
+            </li>
+
+            <li>Struts 1.2.x -
+            Continued refactorings of the Struts 1.x product series.
+                <ul>
+                    <li>Remove deprecations created in the 1.0 to 1.1 timeframe, and prior</li>
+                    <li>Other minor enhancements and refactorings</li>
+                </ul>
+            </li>
+
+            <li>Struts 1.3.x -
+            More substantial enhancements to product base
+                <ul>
+                    <li>Move to Commons Resources</li>
+                    <li>Move taglibs into separate JARs</li>
+                    <li>Enhance all configs to extend one configuration element from another,
+                        as is done with Tiles Definitions</li>
+                </ul>
+            </li>
+
+            <li>Struts 1.4.x -
+            More substantial enhancements to product base
+                <ul>
+                    <li>Consider new Request Processor, if available (which might be based on the Commons Chain
+                        of Responsiblity package)</li>
+                    <li>Consider migration to an Action context (which also might be based no the Commons Chain
+                        of Responsiblity package)</li>
+                    <li>Consider enhanced support for other platforms (2.3/1.2) if this can be accomplished by
+                    specifying an alternate Request Processor</li>
+                </ul>
+            </li>
+
+            <li>Other potential enhancements for the 1.x.x series
+                <ul>
+                    <li>Move to <a href="http://xml.apache.org/forrest/">Forrest</a> or
+                        <a href="http://maven.apache.org/">Maven</a> for project management</li>
+                    <li>Consider adopting several popular extensions, including:
+                        <ul>
+                            <li><a href="http://sslext.sourceforge.net/">SSL Ext</a></li>
+                            <li><a href="http://strutstestcase.sourceforge.net/">TestCase</a></li>
+                            <li><a href="http://stxx.sourceforge.net">Stxx</a> (XLST)</li>
+                            <li><a href="http://www.livinglogic.de/Struts/">Workflow</a></li>
+                            <li><a href="http://struts.sf.net/struts-cocoon/">Cocoon Plugin</a></li>
+                            <li><a href="http://struts.sf.net/struts-bsf/">Scriptable Actions using BSF</a> (Bean Scripting
+                                Framework)</li>
+                        </ul>
+                    </li>
+                </ul>
+            </li>
+
+        </ul>
+
+  <!--
+    <p>
+    Features under discussion include:
+    </p>
+
+    <ul>
+
+        <li>
+        Proposing ActionError/ActionErrors as generic Commons "message" components
+        </li>
+
+        <li>
+        "Nested" or "hierarchical" and locale-sensitive modules
+        </li>
+
+        <li>
+        Extending one configuration element from another, as is done with Tiles
+        Definitions
+        </li>
+
+        <li>
+        Enhanced interoperability with JSTL and JSF
+        </li>
+
+        <li>
+        Making Tiles JSTL-aware and available to other presentation systems (XLST,
+        Velocity)
+        </li>
+
+        <li>
+        Encouraging the use of <a href="http://sourceforge.net/projects/xdoclet/">XDoclet</a> and other code generation technologies to streamline development.
+        </li>
+
+        <li>Moving to <a href="http://jakarta.apache.org/turbine/maven/index.html">
+        Maven</a> for project management
+        </li>
+
+        <li>Regardless of whether a move to Maven happens or not, we need to
+        refactor the source repositories and build scripts for less complexity
+        and easier maintenance.</li>
+
+    </ul>
+    <p>
+    More detail on work-in-progress may be found in
+    <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&amp;resolution=LATER&amp;email1=&amp;emailtype1=substring&amp;emailassigned_to1=1&amp;email2=&amp;emailtype2=substring&amp;emailreporter2=1&amp;bugidtype=include&amp;bug_id=&amp;changedin=&amp;votes=&amp;chfieldfrom=&amp;chfieldto=Now&amp;chfieldvalue=&amp;product=Struts&amp;version=Unknown&amp;version=1.0+Beta+2&amp;version=1.0+Beta+1&amp;version=0.5+Final&amp;version=1.0.2+Final&amp;version=1.0.1+Final&amp;version=1.0+Final&amp;version=1.0+Beta+3&amp;version=1.1+Beta+2&amp;version=1.1+Beta+1&amp;version=Nightly+Build&amp;short_desc=&amp;short_desc_type=allwordssubstr&amp;long_desc=&amp;long_desc_type=allwordssubstr&amp;bug_file_loc=&amp;bug_file_loc_type=allwordssubstr&amp;keywords=&amp;keywords_type=anywords&amp;field0-0-0=noop&amp;type0-0-0=noop&amp;value0-0-0=&amp;cmdtype=doit&amp;order=Bug+Number">Bugzilla</a>.
+    If any of these features are important to you, please don't hesitate to
+    <a href="./faqs/helping.html">help with the development effort</a>.
+    </p>
+-->
+
+</section>
+
+<section href="Struts_2_0" name="Struts 2.0.x">
+
+    <p>
+    Struts 2.x (aka Struts "Next Generation") will include broader enhancements.
+    We anticipate that the implementation will utilize the Servlet 2.4 / JSP 2.0
+    platform, but may optionally support earlier platforms.
+    </p>
+
+    <p>
+    We anticipate that Struts 2.x will rely on JSTL and the JavaServer Faces
+    API as supporting technologies.
+    However, the focus of the Struts framework will remain on the Controller aspect of a Model 2/MVC architecture.
+    The core framework will continue to be both Model and View independent.
+    </p>
+
+    <p>
+    Development of Struts 2.x will include taking a completely fresh look at
+    the architecture.
+    The goal for 2.x will be to incorporate everything we've learned in the past
+    years of Struts usage, and create something even better.
+    Development will follow current best practices, like Test Driven Development,
+    and rely on technologies like Maven for project management.
+    </p>
+
+    <p>
+    Of course, it is anticipated that the Struts team will continue to support
+    the 1.x codebase for a long time with bugfixes and incremental enhancements.
+    (Mainly because many of us will still be using it on our production sites!)
+    Accordingly, it is anticipated that the development of the 2.x and 1.x
+    series will occur in tandem.
+    At some point, 2.x milestones may appear alongside new 1.x releases.
+    </p>
+
+    <p>
+    Target features include:
+    </p>
+
+    <ul>
+
+        <li>
+        Comprehensive unit test coverage for all core features
+        </li>
+
+        <li>
+        Enhanced support for using Struts in large team environments.
+        </li>
+
+        <li>
+        Transparent support for a portlet environment (JSR 168), with minimal-to-no changes in your business logic
+        and pages.
+        </li>
+
+        <li>
+        Direct support for JSTL/JSF taglibs and the JSF API
+        </li>
+
+        <li>
+        Enhanced support for other presentation layers, such as XLST
+        </li>
+
+        <li>
+        Enhanced support for scriptable Actions, using technologies like BSF or Jelly
+        </li>
+
+        <li>
+        Refactoring for new technologies available on the Servlet 2.4/ JSP 2.0 platform
+        </li>
+
+    </ul>
+
+</section>
+
+<section href="Portlets" name="Portlet (JSR-168) Whiteboard">
+    <p>
+        There are three major issues with supporting JSR-168 (and I'm sure a bunch of smaller ones as well):
+    </p>
+
+    <ul>
+
+        <li>
+            Struts APIs assume servlet API objects (ServletContext, ServletRequest, ServletResponse), whereas JSR-168
+            talks aboutPortletContext, PortletRequest, and PortletResponse.
+            We'd either need to change the calling sequence for Action.execute() -- problematic for backwards
+            compatibility -- or fake it somehow in a portlet environment.
+        </li>
+
+        <li>
+            The lifecycle of a portlet request is actually divided into two chunks -- processing and then rendering.
+            From a Struts perspective, that means making sure that the first part of the request processor pipeline
+            need to happen in the "process" part, and the forwarding to the resulting page needs to happen in the
+            "render" part.
+        </li>
+
+        <li>
+            Today, Struts owns the process of calculating URLs for pages and actions.
+            Because it's in a webapp, it knows exactly what to do for the developer.
+            However, in a portlet container it's actually the portal server that manages URLs, so a Struts-based
+            portlet would need to interact with the portlet APIs for this purpose.
+        </li>
+
+    </ul>
+
+    <p>
+        A strong goal should be that a Struts application should be usable either as a webapp or as a portlet, with
+        little (ideally no) changes.
+        Therefore, we should build whatever it takes to support this into the standard Struts distribution, which would
+        then be used in both environments.
+    </p>
+
+</section>
+
+    <section href="jsf" name="JavaServer Faces">
+
+        <p>
+            The <a href="http://java.sun.com/j2ee/javaserverfaces/">JavaServer Faces</a> specification has not been
+            finalized. However, Struts is already providing support for JSF through the Struts Faces taglib. Once JSF
+            is finalized and comes into broad use, it is expected that Struts developers will continue to offer
+            enhancements to make it even easier to use Struts with JSF.
+        </p>
+
+        <p>
+            Right now, there is only one open source project working on a JavaServer Faces implementation,
+            <a href="http://sf.net/projects/myfaces">MyFaces</a>. This work is being done under the
+            <a href="http://www.gnu.org/copyleft/lesser.html">LGPL</a>, which some
+            developers find unacceptable. (If you are interested in this project, we suggest you lobby the developers
+            to adopt a more liberal license, like the <a href="http://apache.org/LICENSE">ASL</a>.)
+        </p>
+
+        <p>
+           Thanks in large part to Apache's advocacy and influence, the <a href="http://jcp.org">Java Community
+           Process</a>, which is responsible for the JavaServer Faces specification, process has been modified so that
+           Apache Software Foundation projects, like Jakarta, can qualify for the certification scholarship (for
+           nonprofits) and access to the TCKs and certify that our application is compliant.
+        </p>
+
+        <p>
+            An certificated-complaint Apache implementation of JavaServer Faces would most definately be a Good Thing.
+            It would not be the reference implementation, but we could treat it like one, and strictly follow the
+            book, in the Apache Way. A strict, high-quality, open-source implementation would most likely become
+            a popular option among containers.
+        </p>
+
+        <p>
+            Work on such an implementation could be undertaken by Struts, either here at Jakarta or after our applying
+            for status as a top-level Apache project. <b>Or</b>, "Apache Faces" could also be undertaken as a separate
+            project, with Struts simply using the technology as we now use technologies from the Commons today.
+        </p>
+
+        <p>
+            However, at this point, there is no "code on the table". Apache products leave decisions such as these to
+            the people who create and maintain the codebase. So, lacking a codebase, no binding decision
+            can be made. But, anyone wishing to pursue an "Apache Faces" implementation should be aware that the option
+            certainly exists.
+        </p>
+
+        <p>
+            Aside from offering a strict implementation of JavaServer Faces, there are many, many other JSF related
+            tools and technologies Apache Faces could provide. These include composite view and validation
+            frameworks (like Tiles and the Validator), frameworks for multi-request transactions, non-HTML markup
+            languages (building on top of Faces for things like XUL or XForms or SVG is easy), non-JSP rendering
+            technologies (pretty much anything that has a way to mark where dynamically created output goes can be
+            adapted), libraries of prebuilt components above and beyond the built-in standard ones (such components
+            work equally well in JSP and non-JSP environments), and all the non-human-UI things based on XML
+            technologies.
+        </p>
+
+        <p>
+            As always, the standard implementation is only the beginning.
+        </p>
+
+        <p>
+            For more about Struts and JavaServer faces, see our <a href="faqs/kickstart.html#jsf">FAQ</a>.
+            For more about JavaServer Faces generally, see also <a href="http://www.jamesholmes.com/JavaServerFaces/">
+            Java Server Faces Resources at JamesHomes.com</a>.
+        </p>
+    </section>
+
+<section href="Proposals" name="Relevant Proposals">
+
+    <ul>
+
+        <li>
+        <a href="http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/">Commons Chain of Responsiblity
+        package</a>
+        </li>
+
+        <li>
+        <a href="http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/">CoRe Request Processor</a>
+        </li>
+
+
+        <li>
+        <a href="proposals/release-plan_1_2_0.html">Release Plan 1.2.0</a> -- unratified DRAFT document
+        </li>
+
+        <li>
+        <a href="proposals/struts-faces.html">struts-faces taglib</a>
+        </li>
+
+    </ul>
+
+</section>
+
+<section>
+    <p class="right">
+    Next: <a href="releases.html">Release Guidelines</a>
+    </p>
+</section>
+
+<section>
+    <p class="version">Website updated from CVS: 2003 NOV 26 by husted.</p>
+    <p class="version">Javadocs updated from CVS: 2003 NOV 26 by husted.</p>
+</section>
+
+</body></document>
diff --git a/build-legacy/core/xdocs/stylesheets/struts.css b/build-legacy/core/xdocs/stylesheets/struts.css
new file mode 100644
index 0000000..67ea402
--- /dev/null
+++ b/build-legacy/core/xdocs/stylesheets/struts.css
@@ -0,0 +1,786 @@
+/* $Id$ */
+	
+body {
+	background: #fff;
+	color: #000;
+}
+
+.app h3, .app h4, .tabs td, .tabs th, .functnbar {
+	background-image: url(../images/nw_maj.gif); 
+	background-repeat: no-repeat;
+}
+
+.functnbar, .functnbar2 {
+	background-color: #aaa;
+}
+
+.functnbar2, .functnbar3 {
+	background-color: #aaa;
+/*	background-image: url(../images/sw_maj_rond.gif); */
+	background-repeat: no-repeat;
+	background-position: bottom left;
+}
+
+.functnbar3 {
+	background-color: #ddd;
+/*	background-image: url(../images/sw_med_rond.gif); */
+}
+
+.functnbar, .functnbar2, .functnbar3 {
+	color: #000;
+}
+
+.functnbar a, .functnbar2 a, .functnbar3 a {
+	color: #000;
+	text-decoration: underline;
+}
+
+#navcolumn .body div, body.docs #toc li li {
+	background-image: url(../images/strich.gif);
+	background-repeat: no-repeat;
+	background-position: .5em .5em;
+}
+
+#searchbox .body div, #navcolumn .body .heading {
+	background-image: none;
+}
+
+a:link, #navcolumn a:visited, .app a:visited, .tasknav a:visited {
+	color: blue;
+}
+
+a:link.selfref, a:visited.selfref {
+	color: #555 !important;
+	text-decoration: none;
+}
+
+a:active, a:hover, #leftcol a:active, #leftcol a:hover {
+	color: #f30 !important;
+}
+
+#leftcol a, #breadcrumbs a {
+	text-decoration: none;
+}
+
+.app h3, .app h4 {
+	color: #fff;
+}
+
+.app h3 {
+	background-color: #333;
+}
+
+.app h3 a:link, .app h3 a:visited, .app h4 a:link, .app h4 a:visited {
+	color: #fff !important;
+	text-decoration: underline;
+}
+
+.app h4 {
+	background-color: #888;
+}
+
+.a td {
+	background: #ddd;
+}
+
+.b td {
+	background: #efefef;
+}
+
+table, th, td {
+	border: none;
+}
+
+div.colbar {
+	background: #eee;
+	border-color: #999 #EEE #EEE #999;
+	border-width: 1px;
+	border-style: solid;
+}
+
+.toolgroup {
+	background: #efefef;
+}
+
+.toolgroup .label {
+	border-bottom: 1px solid #666;
+	border-right: 1px solid #666;
+	background: #ddd;
+	color: #555;
+}
+
+.toolgroup .body {
+	border-right: 1px solid #aaa;
+	border-bottom: 1px solid #aaa;
+}
+
+#breadcrumbs {
+	border-top: 1px solid #fff;
+	background-color: #ccc;
+}
+
+#main {
+	border-top: 1px solid #999;
+}
+
+#rightcol div.www, #rightcol div.help {
+	border: 1px solid #ddd;
+}
+
+body.docs div.docs {
+	background-color: #fff;
+	border-left: 1px solid #ddd;
+	border-top: 1px solid #ddd;
+}
+
+#helptext .label {
+	background-image: url(../images/icon_help_sml.gif);
+	background-repeat: no-repeat;
+	background-position: 97%;
+}
+
+body.docs {
+	background: #eee url(../images/help_logo.gif) top right no-repeat !important;
+}
+
+.docs h3, .docs h4 {
+	border-top: solid 1px #000;
+}
+
+#apphead h2 em {
+	color: #777;
+}
+
+.app th {
+	background-color: #bbb;
+}
+
+.tabs th {
+	border-right: 1px solid #333;
+	background-color: #ddd;
+	color: #fff;
+	border-left: 1px solid #fff;
+}
+
+.tabs td {
+	background-color: #999;
+	border-bottom: 1px solid #fff;
+	border-right: 1px solid #fff;
+	border-left: 1px solid #fff;
+}
+
+.tabs {
+	border-bottom: 6px #ddd solid;
+}
+
+.tabs th, .tabs th a:link, .tabs th a:visited {
+	color: #555;
+}
+
+.tabs td, .tabs td a:link, .tabs td a:visited {
+	color: #fff;
+}
+
+.tabs a {
+	text-decoration: none;
+}
+
+.axial th {
+	background-color: #ddd;
+	color: black;
+}
+
+.alert {
+	background-color: #ff9;
+}
+
+.expandedwaste {
+	background: url(../images/icon_arrowwaste2_sml.gif) no-repeat;
+}
+
+.collapsedwaste {
+	background: url(../images/icon_arrowwaste1_sml.gif) no-repeat;
+}
+
+.filebrowse .expanded, .filebrowse-alt .expanded {
+	background-image: url(../images/icon_arrowfolderopen2_sml.gif);
+	background-repeat: no-repeat;
+}
+
+.filebrowse .collapsed, .filebrowse-alt .collapsed {
+	background-image: url(../images/icon_arrowfolderclosed1_sml.gif);
+	background-repeat: no-repeat;
+}
+
+.filebrowse .leafnode, .filebrowse-alt .leafnode {
+	background-image: url(../images/icon_folder_sml.gif);
+	background-repeat: no-repeat;
+}
+
+.filebrowse .leaf, .filebrowse-alt .leaf {
+	background-image: url(../images/icon_doc_sml.gif);
+	background-repeat: no-repeat;
+}
+
+.sortup {
+	background: url(../images/icon_sortup.gif) no-repeat;
+}
+
+.sortdown {
+	background: url(../images/icon_sortdown.gif) no-repeat;
+}
+
+.collapsedwaste {
+	background: url(../images/icon_arrowwaste1_sml.gif) no-repeat;
+}
+
+body .grid td {
+	border-top: 1px solid #ccc;
+	border-left: 1px solid #ccc;
+	background-color: transparent;
+}
+
+.confirm {
+	color: #090;
+}
+
+.info {
+	color: #069;
+}
+
+.errormessage, .warningmessage, .donemessage, .infomessage {
+	border-top: 5px solid #900;
+	border-left: 1px solid #900;
+	background-image: url(../images/icon_error_lrg.gif);
+	background-repeat: no-repeat;
+	background-position: 5px 1.33em;
+}
+
+.warningmessage {
+	background-image: url(../images/icon_warning_lrg.gif);
+	border-color: #c60;
+}
+
+.donemessage {
+	background-image: url(../images/icon_success_lrg.gif);
+	border-color: #090;
+}
+
+.infomessage {
+	background-image: url(../images/icon_info_lrg.gif);
+	border-color: #069;
+}
+
+.docinfo {
+	background: url(../images/icon_doc_lrg.gif) no-repeat;
+}
+
+.dirinfo {
+	background: url(../images/icon_folder_lrg.gif) no-repeat;
+}
+
+.memberinfo {
+	background: url(../images/icon_members_lrg.gif) no-repeat;
+}
+
+.usergroupinfo {
+	background: url(../images/icon_usergroups_lrg.gif) no-repeat;
+}
+
+.errormark, .warningmark, .donemark, .infomark {
+	background: url(../images/icon_error_sml.gif) no-repeat;
+}
+
+.warningmark {
+	background-image: url(../images/icon_warning_sml.gif);
+}
+
+.donemark {
+	background-image: url(../images/icon_success_sml.gif);
+}
+
+.infomark {
+	background-image: url(../images/icon_info_sml.gif);
+}
+
+.cvsdiff, .cvsblame {
+	background-color: #ccc;
+}
+
+.cvsdiffadd {
+	background-color: #afa;
+}
+
+.cvsdiffremove {
+	background-color: #faa;
+}
+
+.cvsdiffchanges1 {
+	background-color: #ff7;
+}
+
+.cvsdiffchanges2 {
+	background-color: #ff7;
+}
+
+li.selection ul a {
+	background: #fff;
+}
+
+.band1 {
+	color: #fff;
+	background-color: #663;
+}
+
+.band2 {
+	color: #fff;
+	background-color: #66C;
+}
+
+.band3 {
+	background-color: #C99;
+}
+
+.band4 {
+	background-color: #CFF;
+}
+
+.band5 {
+	color: #fff;
+	background-color: #336;
+}
+
+.band6 {
+	color: #fff;
+	background-color: #966;
+}
+
+.band7 {
+	background-color: #9CC;
+}
+
+.band8 {
+	background-color: #FFC;
+}
+
+.band9 {
+	color: #fff;
+	background-color: #633;
+}
+
+.band10 {
+	color: #fff;
+	background-color: #699;
+}
+
+.band11 {
+	background-color: #CC9;
+}
+
+.band12 {
+	background-color: #CCF;
+}
+
+.band13 {
+	color: #fff;
+	background-color: #366;
+}
+
+.band14 {
+	color: #fff;
+	background-color: #996;
+}
+
+.band15 {
+	background-color: #99C;
+}
+
+.band16 {
+	background-color: #FCC;
+}
+
+.app .helplink, #helptext .helplink {
+	cursor: help;
+}
+
+.legend th, .bars th {
+	background-color: #fff;
+}
+
+/* font and text properties, exclusive of link indication, alignment, text-indent */
+body, th, td, input, select {
+	font-family: Verdana, Helvetica, Arial, sans-serif;
+}
+
+code, pre {
+	font-family: 'Andale Mono', Courier, monospace;
+}
+
+body, .app h3, .app h4, #rightcol h3, pre, code, #apphead h2 small, h4, th, td {
+	font-size: x-small;
+	voice-family: "\"}\"";
+	voice-family: inherit;
+	font-size: small;
+}
+
+small, div#footer, div#login, div.tabs th, div.tabs td, input, select, .paginate, .functnbar, .functnbar2, .functnbar3, #breadcrumbs, .courtesylinks, #rightcol div.help, .colbar, .tasknav, body.docs div#toc, #leftcol, .legend, .bars {
+	font-size: xx-small;
+	voice-family: "\"}\"";
+	voice-family: inherit;
+	font-size: x-small;
+}
+
+.tabs td, .tabs th, dt, .tasknav .selfref, #login .username, .selection {
+	font-weight: bold;
+}
+
+li.selection ul {
+	font-weight: normal;
+}
+
+#apphead h2 em {
+	font-style: normal;
+}
+
+#banner h1 {
+	font-size: 1.25em;
+}
+
+/* box properties (exclusive of borders), positioning, alignments, list types, text-indent */
+#bodycol h2 {
+	margin-top: .3em;
+	margin-bottom: .5em;
+}
+
+p, ul, ol, dl, .bars table {
+	margin-top: .67em;
+	margin-bottom: .67em;
+}
+
+h3, h4 {
+	margin-bottom: 0;
+}
+
+form {
+	margin: 0;
+}
+
+#bodycol {
+	padding-left: 12px;
+	padding-right: 12px;
+	width: 100%;
+	voice-family: "\"}\"";
+	voice-family: inherit;
+	width: auto;
+}
+
+html>body #bodycol {
+	width: auto;
+}
+
+.docs {
+	line-height: 1.4;
+}
+
+ol ol {
+	list-style-type: lower-alpha;
+}
+
+ol ol ol {
+	list-style-type: lower-roman;
+}
+
+.app h3, .app h4 {
+	padding: 5px;
+	margin-right: 2px;
+	margin-left: 2px;
+}
+
+.app td, .app th {
+	padding: 2px 3px;
+}
+
+.h3 p, .h4 p, .h3 dt, .h4 dt {
+	margin-right: 7px;
+	margin-left: 7px;
+}
+
+.tasknav {
+	margin-bottom: 1.33em;
+}
+
+div.colbar {
+	padding: 3px;
+	margin: 2px 2px 0;
+}
+
+.tabs {
+	margin-top: .67em;
+	margin-right: 2px;
+	margin-left: 2px;
+	padding-left: 8px;
+}
+
+.tabs td, .tabs th {
+	padding: 3px 9px;
+}
+
+#rightcol div.www, #rightcol div.help {
+	padding: 0 .5em;
+}
+
+body.docs #toc {
+	position: absolute;
+	top: 15px;
+	left: 0px;
+	width: 120px;
+	padding: 0 20px 0 0;
+}
+
+body.docs #toc ul, #toc ol {
+	margin-left: 0;
+	padding-left: 0;
+}
+
+body.docs #toc li {
+	margin-top: 7px;
+	padding-left: 10px;
+	list-style-type: none;
+}
+
+body.docs div.docs {
+	margin: 61px 0 0 150px;
+	padding: 1em 2em 1em 1em !important;
+}
+
+.docs p+p {
+	text-indent: 5%;
+	margin-top: -.67em;
+}
+
+.docs h3, .docs h4 {
+	margin-bottom: .1em;
+	padding-top: .3em;
+}
+
+.functnbar, .functnbar2, .functnbar3 {
+	padding: 5px;
+	margin: .67em 2px;
+}
+
+.functnbar3 {
+	margin-top: 0;
+}
+
+body {
+	padding: 1em;
+}
+
+body.composite, body.docs {
+	margin: 0;
+	padding: 0;
+}
+
+th, td {
+	text-align: left;
+	vertical-align: top;
+}
+
+.right {
+	text-align: right !important;
+}
+
+.center {
+	text-align: center !important;
+}
+
+.axial th, .axial th .strut {
+	text-align: right;
+}
+
+.app .axial td th {
+	text-align: left;
+}
+
+body .stb {
+	margin-top: 1em;
+	text-indent: 0;
+}
+
+body .mtb {
+	margin-top: 2em;
+	text-indent: 0;
+}
+
+.courtesylinks {
+	margin-top: 1em;
+	padding-top: 1em;
+}
+
+dd {
+	margin-bottom: .67em;
+}
+
+.toolgroup {
+	margin-bottom: 6px;
+}
+
+.toolgroup .body {
+	padding: 4px 4px 4px 0;
+}
+
+.toolgroup .label {
+	padding: 4px;
+}
+
+.toolgroup .body div {
+	padding-bottom: .3em;
+	padding-left: 1em;
+}
+
+.toolgroup .body div div {
+	margin-top: .3em;
+	padding-bottom: 0;
+}
+
+.tier1 {
+	margin-left: 0;
+}
+
+.tier2 {
+	margin-left: 1.5em;
+}
+
+.tier3 {
+	margin-left: 3em;
+}
+
+.tier4 {
+	margin-left: 4.5em;
+}
+
+.tier5 {
+	margin-left: 6em;
+}
+
+.tier6 {
+	margin-left: 7.5em;
+}
+
+.tier7 {
+	margin-left: 9em;
+}
+
+.tier8 {
+	margin-left: 10.5em;
+}
+
+.tier9 {
+	margin-left: 12em;
+}
+
+.tier10 {
+	margin-left: 13.5em;
+}
+
+.filebrowse .expanded, .filebrowse .collapsed {
+	padding-left: 34px;
+}
+
+.filebrowse .leafnode, .filebrowse .leaf {
+	padding-left: 20px;
+}
+
+.messagechild {
+	padding-left: 34px;
+}
+
+.filebrowse-alt .expanded, .filebrowse-alt .collapsed, .filebrowse-alt .leaf, .filebrowse-alt .leafnode, .expandedwaste, .collapsedwaste, .sortup, .sortdown {
+	/* hide from macie5\*/
+	float: left;
+	/* resume */
+	display: inline-block;
+	height: 15px;
+	width: 34px;
+	padding-left: 0 !important;
+}
+
+.filebrowse-alt .leaf, .filebrowse-alt .leafnode, .sortup, .sortdown {
+	width: 20px;
+}
+
+.filebrowse ul, .filebrowse-alt ul {
+	list-style-type: none;
+	padding-left: 0;
+	margin-left: 0;
+}
+
+.filebrowse ul ul, .filebrowse-alt ul ul {
+	margin-left: 1.5em;
+	margin-top: 0;
+	padding-top: .67em;
+}
+
+.filebrowse li, .filebrowse-alt li {
+	margin-bottom: .67em;
+}
+
+td.filebrowse h3 {
+	margin-top: 0;
+}
+
+.errormessage, .warningmessage, .donemessage, .infomessage, .docinfo, .dirinfo, .memberinfo, .usergroupinfo {
+	margin: .67em 0;
+	padding: .33em 0 .67em 42px;
+	min-height: 32px;
+}
+
+.errormark, .warningmark, .donemark, .infomark {
+	padding-left: 20px;
+	min-height: 15px;
+}
+
+.alt {
+	display: none;
+}
+
+#banner h1 {
+	margin: 0;
+}
+
+#leftcol {
+	width: 14em;
+}
+
+.axial th, .axial th .strut, #leftcol .strut {
+	width: 12em;
+}
+
+#breadcrumbs {
+	padding: 2px 8px;
+}
+
+.app h3, .app h4, .bars {
+	clear: both;
+}
+
+.legend {
+	float: right;
+}
+
+.legend th, .bars th {
+	text-align: right;
+	padding-left: 1em;
+}
+
+.bars table {
+	table-layout: fixed;
+}
+
+.bars th {
+	width: 12em;
+}
+
+#projectdocumentlist td.filebrowse-alt {
+	padding-right: .75em;
+}
diff --git a/build-legacy/core/xdocs/tiles/installation.xml b/build-legacy/core/xdocs/tiles/installation.xml
new file mode 100644
index 0000000..586f9f1
--- /dev/null
+++ b/build-legacy/core/xdocs/tiles/installation.xml
@@ -0,0 +1,346 @@
+<?xml version="1.0"?>
+<document url="./installation.xml">
+<properties>
+  <title>The Tiles 1.1 Framework Project - Installation (1.1)</title>
+</properties>
+
+<body>
+
+<section name="Quick Install for Testing, Documentation and Tutorial"
+         href="QuickInstall">
+    <ul>
+        <li>Download Tiles binary distribution</li>
+        <li>Unzip distribution</li>
+        <li>Copy <code>web/tiles-doc.war</code> or <code>web/struts-tiles.war</code>
+            in  your web server webapps directory (webapps with Tomcat).
+            Please refer to your webserver manual to know exactly where, or
+            check <a href="#Containers">detailed install</a>.</li>
+        <li>Restart your web server if necessary</li>
+        <li>Point your browser to the root of newly installed web application
+            (<a href="http://localhost:8080/tiles-doc">
+            http://localhost:8080/tiles-doc</a>
+             or <a href="http://localhost:8080/struts-tiles">
+             http://localhost:8080/struts-tiles</a>
+            with tomcat</li>
+    </ul>
+
+    <p>Quick start and setting of a new application using Tiles</p>
+    <ul>
+        <li>Take appropriate <code>tiles-blank.war</code> and
+            copy it in your web server webapps directory
+            <ul>
+                <li><code>tiles-blank.war</code> - Tiles
+                    without Struts</li>
+                <li><code>tiles-blank-struts1.1.war</code> -
+                    Tiles with Struts1.1</li>
+                <li><code>tiles-blank-struts1.0.war</code> -
+                    Tiles with latest stable Struts1.0.x</li>
+            </ul>
+        </li>
+        <li>These war files are not distributed with Struts binaries.</li>
+    </ul>
+</section>
+
+<section name="Prerequisite Software" href="Prerequisites">
+    <p>Copyright : This page is largely inspired from the original
+       <a href="http://jakarta.apache.org/struts">Struts installation page</a>.
+       For those familiar with Struts, there is nothing really new.</p>
+
+    <p>The Tiles binary distribution needs other software packages installed
+       to operate. You may already have these installed on your system. To
+       build Tiles from source you may need to acquire and install several
+       others. The complete list is as follows:</p>
+
+    <ul>
+        <li><strong>Java Development Kit</strong> -
+            You <strong>must</strong> download and install a Java2 (version
+            1.2 or later) Java Development Kit implementation for your
+            operating system platform. A good starting point for locating Java
+            Development Kit distributions is <a href="http://java.sun.com/j2se">
+            http://java.sun.com/j2se</a>.
+        </li>
+        <li><strong>Servlet Container</strong> -
+            You <strong>must</strong> download and install a servlet container
+            that is compatible with the Servlet API Specification, version 2.2
+            or later, and the JavaServer Pages (JSP) Specification, version 1.1
+            or later. One popular choice is to download Apache's
+            <a href="http://jakarta.apache.org/tomcat">Tomcat</a>
+            (version 3.1 or later required, version 3.2 or later recommended).</li>
+        <li><strong>XML Parser</strong> - Tiles <strong>requires</strong> the
+            presence of an XML parser that is compatible with the Java API for
+            XML Parsing (JAXP) specification, 1.1 or later. You can download
+            and install the JAXP <a href="http://java.sun.com/xml">reference
+            implementation</a>, which is required for building the Tiles
+            source distribution. In Tiles-based web applications, you may
+            replace the reference implementation classes with any other JAXP
+            compliant parser, such as <a href="http://xml.apache.org/xerces-j">
+            Xerces</a>. See detailed    instructions related to the parser in
+            the instructions for <a href="#Building">building</a> and
+            <a href="#Installing">installing</a> Tiles, below. </li>
+        <li><strong>Ant Build System</strong> -
+            If you are building Tiles from the source distribution, you must
+            download and install version 1.3 or later of the
+            <a href="http://jakarta.apache.org/ant">Ant</a> build system.
+            This package is also strongly recommended for use in developing
+            your own web applications based on Tiles.
+        <ul>
+            <li>If you are using the release version of Ant version 1.3, you
+                will also need to download the "optional.jar" file that
+                contains the implementation of Ant's <code>&lt;style&gt;</code>
+                command. </li>
+            <li>Make sure that the "ant" and "ant.bat" scripts
+                are executable, by adding the $ANT_HOME/bin directory to your
+                PATH environment variable. </li>
+        </ul>
+        </li>
+        <li><strong>Servlet API Classes</strong> - In order to compile Tiles
+            itself, or applications that use Tiles, you will need a
+            <code>servlet.jar</code> file containing the Servlet and JSP API
+            classes. Most servlet containers include this JAR file. Otherwise,
+            you can get the Servlet API classes distribution from
+            <a href="http://jakarta.apache.org/builds/jakarta-servletapi">
+            here</a>.
+        </li>
+        <li><strong>Jakarta Commons Packages</strong> -
+            Tiles utilizes several    packages from the
+            <a href="http://jakarta.apache.org/commons/">Jakarta Commons
+            Project</a>.If you are utilizing a binary distribution of Tiles,
+            the corresponding JAR files are included in the <code>lib</code>
+            directory. However, if you wish to build Tiles from source, you
+            will need to download and install the following packages:
+
+        <ul>
+                <li><em>Beanutils</em> (Version 1.0 or later)</li>
+                <li><em>Collections</em> (Version 1.0 or later)</li>
+                <li><em>Digester</em> (Version 1.0 or later)</li>
+                <li><em>Logging</em> (Version 1.0 or later)</li>
+        </ul>
+        </li>
+        <li><strong>Xalan XSLT Processor</strong> -
+            If you are building Tiles from the source distribution, you will
+            need a version of Xalan to perform XSLT transformations. If you
+            are using the JAXP/1.1 XML parser, you    should use the version
+            of <code>xalan.jar</code> shipped with it. Otherwise, download
+            and install version 1.2 of Xalan from
+            <a href="http://xml.apache.org/xalan">here</a>.
+        </li>
+        <li><strong>Struts Framework</strong> - If you are planning to use
+            Tiles with Struts, you should download and install Struts from
+            <a href="http://jakarta.apache.org/struts/">
+            Jakarta Struts Project</a>.
+            If you have acquired Tiles with the Struts distribution, you
+            don't need to install it again. Tiles can run without Struts.
+            In this case you loose some features.</li>
+    </ul>
+</section>
+
+<section name="Install A Tiles Binary Distribution" href="Installing">
+    <p>First, download a binary distribution of Tiles by following the
+       instructions <a href="download.jsp">here</a>.
+       Then, make sure    you have downloaded and installed the
+       <a href="#Prerequisites">prerequisite</a> software packages described
+       above.</p>
+    <p>Unpack the Tiles binary distribution into a convenient directory.
+       (If you <a href="#Building">build Tiles from the source distribution</a>,
+       the result of the build will already be an unpacked binary distribution
+       for you). The distribution consists of the following contents:</p>
+    <ul>
+        <li><strong>lib/tiles.jar</strong> - This JAR file contains all of
+            the Java classes included in Tiles. It should be copied into the
+            <code>WEB-INF/lib</code>directory of your web application.
+            <em>WARNING</em> - If you are going to be hosting multiple tiles
+            based applications on the same servlet container, you will be
+            tempted to place the <code>struts.jar</code> file into the shared
+            repository supported by your container. Be advised that this will
+            likely cause you to encounter ClassNotFoundException problems
+            unless <em>all</em> of your application classes are stored in the
+            shared repository.
+        </li>
+        <li><strong>lib/struts1.0/tilesForStruts1.0.jar</strong> -
+            Same as before,    but for use with Struts1.0.x. </li>
+        <li><strong>lib/tiles.tld</strong> - These is the "tag library
+            descriptor" file that describe the custom tags in the Tiles tag
+            libraries. It should be copied into the <code>WEB-INF</code>
+            directory of your web application.
+        </li>
+        <li><strong>webapps/tiles-doc.war</strong> or
+            <strong>webapps/struts-tiles.war</strong> - This is a
+            "web application archive" file containing all of the Tiles
+            documentation found on the
+            <a href="http://www.lifl.fr/~dumoulin/tiles/">Tiles web site</a>
+            (including these pages). You can install this web application
+            on any servlet container compatible with Servlet API 2.2 or later.
+        </li>
+        <li><strong>webapps/tiles-channel.war</strong> - Examples using a
+            custom definition factory.</li>
+        <li><strong>webapps/tiles-blank.war</strong> - A blank application
+            that can be used as a starting point when you want to develop
+            your own application with Tiles. This blank application doesn't
+            contains neither use Struts. If you also want to use Struts,
+            add struts.jar and related tld files, or choose one of the
+            following applications. </li>
+        <li><strong>webapps/tiles-blank-struts1.1.war</strong> -
+            A blank application to use with Struts1.1 </li>
+        <li><strong>webapps/tiles-blank-struts1.0.war</strong> -
+            A blank application to use with Struts1.0.x </li>
+    </ul>
+    <p>To use Tiles in your own application, you will need to follow
+       these steps:</p>
+    <ul>
+        <li>Copy the files<code>lib/commons-*.jar</code> into
+            the <code>WEB-INF/lib</code> directory of your web application.
+        </li>
+        <li>Copy the file <code>lib/tiles.jar</code> from
+            the Tiles distribution    into the <code>WEB-INF/lib</code>
+            directory of your web application.
+        </li>
+        <li>Copy all of the files that match <code>lib/*.tld</code> from
+            the Tiles    distribution into the <code>WEB-INF</code> directory
+            of your web application.
+        </li>
+        <li>If you want to use <em>definitions configuration file</em>, you
+            need to initialize the definitions factory. This can be done as follows:
+        <ul>
+            <li>Modify the <code>WEB-INF/web.xml</code> file
+                for your web application to use a <code>&lt;servlet&gt;
+                </code> that initializes the factory and catch Struts action
+                forwards to check for definition name. Use the
+                <code>WEB-INF/web.xml</code> file from the Tiles example
+                application for a detailed example of the required syntax.
+            <pre>
+  &lt;servlet&gt;
+     ...
+     &lt;servlet-name&gt;action&lt;/servlet-name&gt;
+     &lt;servlet-class&gt;org.apache.struts.tiles.ActionComponentsServlet&lt;/servlet-class
+     &lt;init-param&gt;
+       &lt;param-name&gt;definitions-config&lt;/param-name&gt;
+       &lt;param-value&gt;/WEB-INF/tiles-config.xml&lt;/param-value&gt;
+     &lt;/init-param&gt;
+     ...
+</pre>
+            </li>
+            <li>If you don't want to use Struts, use
+                <code>org.apache.struts.tiles.TilesServlet</code> as servlet.
+            </li>
+            <li>Create a configuration file for definitions. Its name must
+                match the one provided before in <code>WEB-INF/web.xml</code>.
+                Several comma separated names can be provided.
+            </li>
+        </ul>
+        </li>
+        <li>Modify the <code>WEB-INF/web.xml</code> file of your web application
+            to include the following tag library declarations: </li>
+    </ul>
+<pre>&lt;taglib&gt;
+  &lt;taglib-uri&gt;/WEB-INF/tiles.tld&lt;/taglib-uri&gt;
+  &lt;taglib-location&gt;/WEB-INF/tiles.tld&lt;/taglib-location&gt;
+&lt;/taglib&gt;
+</pre>
+
+    <ul>
+        <li>At the top of each JSP page that will use the Tiles custom tags,
+            add line(s) declaring the Tiles custom tag libraries used on this
+            particular page, like this:</li>
+    </ul>
+<pre>&lt;%@ taglib uri="/WEB-INF/tiles.tld" prefix="tiles" %&gt;
+</pre>
+    <ul>
+        <li>When compiling the Java classes that comprise your application,
+            be sure to include the <code>tiles.jar</code> and
+            <code>commons-*.jar</code> files (copied earlier) on the
+            CLASSPATH that is submitted to the compiler.</li>
+    </ul>
+    <p>Note to Struts 1.0 users :</p>
+    <ul>
+        <li>You should use a <code>tiles.jar</code> build with Struts1.0.x.</li>
+        <li>If you have downloaded a Tiles version build with Struts1.0.x, you
+            already have it. </li>
+        <li>Consider to use tilesForStruts1.0.jar located in
+            <code>lib/struts1.0</code></li>
+    </ul>
+
+    <p>Note to Struts1.1 users :</p>
+    <ul>
+        <li>You should also initialize a <code>TilesRequestProcessor</code>.</li>
+        <li>To do so, add following lines in your <code>struts-config.xml</code>
+            file :
+<pre>
+   &lt;controller processorClass="org.apache.struts.tiles.TilesRequestProcessor"&gt;
+   &lt;/controller&gt;
+</pre>
+        </li>
+    </ul>
+</section>
+
+<section name="Installing Tiles with your servlet container" href="Containers">
+    <p><strong>WARNING</strong> - Do <strong>NOT</strong> add
+       <code>tiles.jar</code> to the classpath of your servlet container in
+       an attempt to avoid placing it in the <code>/WEB-INF/lib</code>
+       directory of each individual web app! Doing so will cause problems with
+       <code>ClassNotFoundException</code> exceptions. </p>
+
+    <p>For most containers, you need only to:</p>
+    <ul>
+        <li>Copy the WAR files in your Tiles <code>/webapp</code> directory
+            to your    containers <code>webapps</code> directory. </li>
+        <li>In some cases, you may need to restart your container if it
+            is running.</li>
+    </ul>
+
+    <h4>Status of various containers</h4>
+    <p>For status of additional containers, please refer to the
+        <a href="installation.html#Installing"> Struts installation page</a>).
+    </p>
+</section>
+
+<section name="Building Tiles From Source" href="Building">
+    <p>First, download a source distribution of Tiles from
+       <a href="http://www.lifl.fr/~dumoulin/tiles/">here</a> or
+       from Struts contrib directory. Then, make sure you have downloaded and
+       installed <strong>all</strong> of the
+       <a href="#Prerequisites">prerequisite</a> software packages described
+       above. You also need the appropriate struts version (1.0.x or 1.1)</p>
+    <p>To build Tiles, you will need to customize the build process to the details
+        of your development environment as follows: </p>
+    <ul>
+        <li>The Tiles source distribution uses a file named
+            <code>build.properties</code> (in the top-level directory of the
+            distribution) to identify the location of external components
+            that Tiles depends on.</li>
+        <li>There is no <code>build.properties</code> file included with the
+            source distribution. However, there is an example file named
+            <code>build.properties.example</code> that you can copy to
+            <code>build.properties</code>and then customize.</li>
+        <li>The properties you must configure in <code>build.properties</code> are
+            documented in <code>build.properties.example</code> </li>
+        <li>Tiles build require a Struts library. You can use either a
+            Struts1.0.x or 1.1 <code>struts.jar</code>. The resulting
+            <code>tiles.jar</code> will run with the used <code>struts.jar</code>.
+            You specify the Struts home with <code>struts.home</code> property.
+        </li>
+    </ul>
+    <p>To build a "distribution" version of Tiles, first change your current
+        directory to the directory in which you have unpacked the Tiles
+        source distribution, and (if necessary) create or customize the
+        <code>build.properties</code>file as described above. Then, type:
+    </p>
+<pre>
+        ant dist
+</pre>
+
+    <p>This command will create a binary distribution of Tiles, in a
+       directory named <code>dist</code> (relative to where you are
+       compiling from). This directory contains an exact replica of
+       the files included in a binary distribution of Tiles, as described
+       in the <a href="Installing">preceding section</a>.</p>
+    <p>IMPORTANT NOTE: The <code>tiles.jar</code>, as well as the JAR
+        files from the Jakarta Commons project, must be in your classpath
+        when compiling Tiles. The <code>build.xml</code> provided does this
+        automatically. If you use your development machine to test Tiles
+        application locally, be sure that the <code>tiles.jar</code>is
+        <strong>NOT</strong> on your classpath when your container is
+        running.
+    </p>
+</section>
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/tiles/project.xml b/build-legacy/core/xdocs/tiles/project.xml
new file mode 100644
index 0000000..c3c41b7
--- /dev/null
+++ b/build-legacy/core/xdocs/tiles/project.xml
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<project name="Apache Struts Web Application Framework"
+         href="http://jakarta.apache.org/struts"
+        image="images/struts.gif">
+
+    <title>The Tiles 1.1 Framework Project - Installation (1.1)</title>
+
+    <menu name="Tiles">
+        <item href="index.jsp" name="Tiles Home"/>
+    </menu>
+
+    <menu name="Examples">
+        <item href="examples/index.jsp" name="Home"/>
+    </menu>
+
+    <menu name="Documentation">
+        <item href="doc/index.jsp" name="Home"/>
+        <item href="examples/index.jsp" name="Examples"/>
+        <item href="test/quickOverview.jsp" name="Quick overview"/>
+        <item href="doc/index.jsp" name="Home"/>
+        <item href="tutorial/index.jsp" name="Tutorial Live Examples"/>
+    </menu>
+
+</project>
+
+
+
+
+
+
diff --git a/build-legacy/core/xdocs/userGuide/building_controller.xml b/build-legacy/core/xdocs/userGuide/building_controller.xml
new file mode 100644
index 0000000..4920287
--- /dev/null
+++ b/build-legacy/core/xdocs/userGuide/building_controller.xml
@@ -0,0 +1,1567 @@
+<?xml version="1.0"?>
+<document url="building_controller.html">
+
+<!--
+// ======================================================================== 78
+-->
+
+<properties>
+    <title>The Struts User Guide - Building Controller Components</title>
+</properties>
+
+<body>
+<section name="4. Building Controller Components" href="building_controller"/>
+
+<section name="4.1 Overview" href="overview">
+
+    <p>
+    Now that we understand how to construct the Model and View components
+    of your application, it is time to focus on the <code>Controller</code>
+    components.  
+    Struts includes a servlet that implements the primary function of mapping 
+    a request URI to an <code>Action</code> class.  
+    Therefore, your primary responsibilities related to the Controller are:
+    </p>
+
+    <ul>
+    
+        <li>
+        Write an <code>ActionForm</code> class to mediate between the Model
+        and the View, as described in <a href="building_model.html">Building
+        Model Components</a>.
+        </li>
+
+        <li>
+        Write an <code>Action</code> class for each logical request that may
+        be received (extend <code>org.apache.struts.action.Action</code>).
+        </li>
+
+        <li>
+        Configure a ActionMapping (in XML) for each logical request that may
+        be submitted. 
+        The XML configuration file is usually named 
+        <code>struts-config.xml</code>.
+        </li>
+
+    </ul>
+    
+    <p>
+    To deploy your application, you will also need to:
+    </p>
+    
+    <ul>
+
+        <li>
+        Update the web application deployment descriptor file (in XML)
+        for your application to include the necessary Struts components.
+        </li>
+
+        <li>
+        Add the appropriate Struts components to your application.
+        </li>
+        
+    </ul>
+    
+    <p>
+    The latter two items are covered in the 
+    "<a href="configuration.html">Configuring Applications</a>" chapter.
+    </p>
+
+</section>
+
+<section name="4.2 The ActionServlet" href="action_servlet">
+
+    <p>
+    For those of you familiar with MVC architecture, the ActionServlet
+    represents the C - the controller.  
+    The job of the controller is to:
+    </p>
+    
+    <ul>
+    
+    <li>
+    process user requests, 
+    </li>
+    
+    <li>
+    determine what the user is trying to achieve according to the request, 
+    </li>
+    
+    <li>
+    pull data from the model (if necessary) to be given to the appropriate 
+    view, and 
+    </li>
+    
+    <li>
+    select the proper view to respond to the user.  
+    </li>
+    
+    </ul>
+    
+    <p>
+    The Struts controller delegates most of this grunt work to Action classes.
+    </p>
+    
+    <p>
+    In addition to being the controller for your application, the
+    ActionServlet instance also is responsible for initialization and
+    clean-up of resources.  
+    When the controller initializes, it first loads the application config 
+    corresponding to the "config" init-param.
+    It then goes through an enumeration of all <code>init-param</code>
+    elements, looking for those elements who's name starts with
+    <code>config/</code>.  
+    For each of these elements, Struts loads the configuration file specified 
+    by the value of that <code>init-param</code>, and assigns a "prefix" 
+    value to that module's ModuleConfig instance consisting of the piece
+    of the <code>init-param</code> name following "config/".  
+    For example, the module prefix specified by the 
+    <code>init-param config/foo</code> would be "foo". 
+    This is important to know, since this is how the controller determines 
+    which module will be given control of processing the request.  
+    To access the module foo, you would use a URL like:
+    </p>
+    
+    <pre>http://localhost:8080/myApp/foo/someAction.do</pre>
+    
+    <p>
+    For each request made of the controller, the method
+    <code>process(HttpServletRequest, HttpServletResponse)</code> will be
+    called.  
+    This method simply determines which module should service the request and 
+    then invokes that module's RequestProcessor's process method, passing the 
+    same request and response.
+    </p>
+
+</section>
+
+<section name="4.2.1 Request Processor" href="request_processor">
+
+    <p>
+    The RequestProcessor is where the majority of the core processing 
+    occurs for each request.  
+    Let's take a look at the helper functions the process method invokes 
+    in-turn:
+    </p>
+
+    <table>
+    <tr>
+        <td>
+        <code>processPath</code>
+        </td>
+        <td>
+        Determine the path that invoked us.  
+        This will be used later to retrieve an ActionMapping.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processLocale</code>
+        </td>
+        <td>
+        Select a locale for this request, if one hasn't already been 
+        selected, and place it in the request.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processContent</code> 
+        </td>
+        <td>
+        Set the default content type (with optional character encoding) for 
+        all responses if requested.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processNoCache</code>
+        </td>
+        <td>
+        If appropriate, set the following response headers: "Pragma", 
+        "Cache-Control", and "Expires".
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processPreprocess</code>
+        </td>
+        <td>
+        This is one of the "hooks" the RequestProcessor makes available for 
+        subclasses to override.  
+        The default implementation simply returns <code>true</code>.  
+        If you subclass RequestProcessor and override processPreprocess you 
+        should either return <code>true</code> (indicating process should 
+        continue processing the request) or <code>false</code> (indicating 
+        you have handled the request and the process should return)
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processMapping</code> 
+        </td>
+        <td>
+        Determine the ActionMapping associated with this path.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processRoles</code> 
+        </td>
+        <td>
+        If the mapping has a role associated with it, ensure the requesting 
+        user is has the specified role.  
+        If they do not, raise an error and stop processing of the request.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processActionForm</code> 
+        </td>
+        <td>
+        Instantiate (if necessary) the ActionForm associated with this 
+        mapping (if any) and place it into the appropriate scope.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processPopulate</code>
+        </td>
+        <td>
+        Populate the ActionForm associated with this request, if any.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+        <code>processValidate</code> 
+        </td>
+        <td>
+        Perform validation (if requested) on the ActionForm associated with 
+        this request (if any).
+        </td>
+    </tr>
+    
+    <tr>
+        <td>
+        <code>processForward</code>
+        </td>
+        <td>
+        If this mapping represents a forward, forward to the path specified 
+        by the mapping.
+        </td>
+    </tr>
+    
+    <tr>
+        <td>
+        <code>processInclude</code> 
+        </td>
+        <td>
+        If this mapping represents an include, include the result of 
+        invoking the path in this request.
+        </td>
+    </tr>
+    
+    <tr>
+        <td>
+        <code>processActionCreate</code>
+        </td>
+        <td>
+        Instantiate an instance of the class specified by the current 
+        ActionMapping (if necessary).
+        </td>
+    </tr>
+    
+    <tr>
+        <td>
+        <code>processActionPerform</code> 
+        </td>
+        <td>
+        This is the point at which your action's <code>perform</code> or 
+        <code>execute</code> method will be called.
+        </td>
+    </tr>
+
+    <tr>
+        <td>
+         <code>processForwardConfig</code>
+        </td>
+        <td>
+        Finally, the process method of the RequestProcessor takes the 
+        ActionForward returned by your Action class, and uses to select the 
+        next resource (if any).
+        Most often the ActionForward leads to the presentation page that
+        renders the response.
+        </td>
+    </tr>
+
+    </table>
+
+</section>
+
+<section name="4.3 ActionForm Classes" href="action_form_classes">
+
+    <p>
+    An ActionForm represents an HTML form that the user interacts with over 
+    one or more pages.  
+    You will provide properties to hold the state of the form with getters 
+    and setters to access them.  
+    ActionForms can be stored in either the session (default) or request 
+    scopes.  
+    If they're in the session it's important to implement the form's 
+    <code>reset</code> method to initialize the form before each use.  
+    Struts sets the ActionForm's properties from the request parameters and 
+    sends the validated form to the appropriate Action's <code>execute</code> 
+    method.
+    </p>
+
+    <p>
+    When you code your <code>ActionForm</code> beans, keep the following
+    principles in mind:
+    </p>
+
+    <ul>
+    
+    <li>
+    The <code>ActionForm</code> class itself requires no specific
+    methods to be implemented.  
+    It is used to identify the role these particular beans play in the overall 
+    architecture.  
+    Typically, an <code>ActionForm</code> bean will have only property getter 
+    and property setter methods, with no business logic.
+    </li>
+    
+    <li>
+    The ActionForm object also offers a standard validation mechanism.
+    If you override a "stub" method, and provide error messages in the
+    standard application resource, Struts will automatically validate the
+    input from the form (using your method). 
+    See "<a href="./building_view.html#form_validation">
+    Action Form Validation</a>" for details. 
+    Of course, you can also ignore the ActionForm validation and provide your 
+    own in the Action object.
+    </li>
+
+    <li>
+    Define a property (with associated <code>getXxx</code> and
+    <code>setXxx</code> methods) for each field that is present in the
+    form.  
+    The field name and property name must match according to the usual 
+    JavaBeans conventions (see the Javadoc for the 
+    <code>java.beans.Introspector</code> class for a start on information
+    about this).  
+    For example, an input field named <code>username</code> will cause the 
+    <code>setUsername</code> method to be called.
+    </li>
+
+    <li>
+    Buttons and other controls on your form can also be defined as properties.
+    This can help determine which button or control was selected when the
+    form was submitted. 
+    Remember, the ActionForm is meant to represent your data-entry form, not 
+    just the data beans.
+    </li>
+    
+    <li>
+    Think of your ActionForm beans as a firewall between HTTP and the Action.
+    Use the <code>validate</code> method to ensure all required properties 
+    are present, and that they contain reasonable values. 
+    An ActionForm that fails validation will not even be presented to the 
+    Action for handling.
+    </li>
+    
+    <li>
+    You may also place a bean instance on your form, and use nested property
+    references. 
+    For example, you might have a "customer" bean on your ActionForm, and 
+    then refer to the property "customer.name" in your presentation page.
+    This would correspond to the methods <code>customer.getName()</code> and
+    <code>customer.setName(string Name)</code> on your customer bean. 
+    See the Tag Library Developer Guides for more about using nested syntax 
+    with the Struts JSP tags.
+    </li>
+    
+    <li>
+    <em>Caution:</em> If you nest an existing bean instance on your form, think
+    about the properties it exposes. 
+    Any public property on an ActionForm that accepts a single String value 
+    can be set with a query string. 
+    It may be useful to place beans that can affect the business state inside 
+    a thin "wrapper" that exposes only the properties required. 
+    This wrapper can also provide a filter to be sure runtime properties are 
+    not set to inappropriate values.
+    </li>
+    
+    </ul>
+
+</section>
+
+<section name="4.3.1 DynaActionForm Classes" href="dyna_action_form_classes">
+
+    <p>
+    Maintaining a separate concrete ActionForm class for each form in your 
+    Struts application is time-consuming.
+    It is particularly frustrating when all the ActionForm does is gather
+    and validate simple properties that are passed along to a business
+    JavaBean.
+    </p>
+    <p>
+    This bottleneck can be alleviated through the use of DynaActionForm classes.
+    Instead of creating a new ActionForm subclass and new get/set methods for 
+    each of your bean's properties, you can list its properties, type, and 
+    defaults in the Struts configuration file.
+    </p>
+    
+    <p>
+    For example, add the following to struts-config.xml for a UserForm bean 
+    that stores a user's given and family names:
+    </p>
+    
+<pre><code><![CDATA[
+<form-bean 
+    name="UserForm" 
+    type="org.apache.struts.action.DynaActionForm">
+    <form-property 
+        name="givenName" 
+        type="java.lang.String" 
+        initial="John"/>
+    <form-property 
+        name="familyName" 
+        type="java.lang.String" 
+        initial="Smith"/>
+</form-bean>
+]]></code></pre>
+
+    <p>
+    The types supported by DynaActionForm include:
+    </p>
+    
+    <ul>
+    
+        <li>
+        java.lang.BigDecimal
+        </li>
+
+        <li>
+        java.lang.BigInteger
+        </li>
+
+        <li>
+        boolean and java.lang.Boolean
+        </li>
+
+        <li>
+        byte and java.lang.Byte
+        </li>
+
+        <li>
+        char and java.lang.Character
+        </li>
+
+        <li>
+        java.lang.Class
+        </li>
+
+        <li>
+        double and java.lang.Double
+        </li>
+
+        <li>
+        float and java.lang.Float
+        </li>
+
+        <li>
+        int and java.lang.Integer
+        </li>
+
+        <li>
+        long and java.lang.Long
+        </li>
+
+        <li>
+        short and java.lang.Short
+        </li>
+
+        <li>
+        java.lang.String
+        </li>
+
+        <li>
+        java.sql.Date
+        </li>
+
+        <li>
+        java.sql.Time
+        </li>
+
+        <li>
+        java.sql.Timestamp
+        </li>
+    
+    </ul>
+
+    <p>
+        You may also specify Arrays of these types (e.g. <code>String[]</code>).
+        You may also specify a concrete implementation of the Map Interface,
+        such as <code>java.util.HashMap</code>,
+        or a List implementation, such as <code>java.util.ArrayList</code>.
+    </p>
+
+    <p>
+    If you do not supply an initial attribute, numbers will be initialized to 
+    0 and objects to <code>null</code>.
+    </p>
+    
+    <p>
+    In JSP pages using the original Struts custom tags, attributes of
+    <code>DynaActionForm</code> objects can be referenced just like ordinary
+    <code>ActionForm</code> objects. Wherever a Struts tag refers to a
+    "property", the tags will automatically use the DynaActionForm properties
+    just like those of a conventional JavaBean.
+    You can even expose DynaActionForm properties using bean:define.
+    (Although, tou can't use bean:define to <strong>instantiate</strong> a DynaActionForm,
+    since it needs to be setup with the appropriate dyna-properties).
+    </p>
+
+    <p>
+    If you are using the Struts JSTL EL taglib, the references are different,
+    however.
+    Only properties of ordinary <code>ActionForm</code> objects can be directly
+    accessed through the JSTL expression language syntax.  
+    The <code>DynaActionForm</code> properties must be accessed through a
+    slightly different syntax. 
+    The JSTL EL syntax for referencing a property
+    of an <code>ActionForm</code> goes like this:
+    </p>
+    
+<pre><code>${formbean.prop}</code></pre>
+    
+    <p>
+    The syntax for referencing a property of a <code>DynaActionForm</code>
+    would be:
+    </p>
+
+<pre><code>${dynabean.map.prop}</code></pre>
+
+    <p>
+    The <code>map</code> property is a property of 
+    <code>DynaActionForm</code> which represents the <code>HashMap</code>
+    containing the <code>DynaActionForm</code> properties.
+    </p>
+
+    <p>
+    DynaActionForms are meant as an easy solution to a common problem:
+    <em>Your ActionForms use simple properties and standard validations,
+    and you just pass these properties over to another JavaBean</em>
+    (say using <code>BeanUtils.copyProperties(myBusinessBean,form)</code>).
+    </p>
+
+    <p>
+    DynaActionForms are <strong>not</strong> a drop-in replacement for ActionForms.
+    If you need to access ActionForm properties in your Action, you will need to
+    use the map-style accessor, like <code>myForm.get("name")</code>.
+    If you actively use the ActionForm object in your Action,
+    then you may want to use conventional ActionForms instead.
+    </p>
+
+    <p>
+    DynaActionForms cannot be instantiated using a no-argument constructor.
+    In order to simulate the extra properties,
+    there is a lot of machinery involved in their construction.
+    You must rely on Struts to instantiate a DynaActionForm for you,
+    via the ActionMapping.
+    </p>
+
+    <p>
+    If need be, you can extend the DynaActionForm to add custom
+    validate and reset methods you might need.
+    Simply specify your subclass in the struts-config instead.
+    However, you cannot mix conventional properties and DynaProperties.
+    A conventional getter or setter on a DynaActionForm won't be found
+    by the reflection utilities.
+    </p>
+
+    <p>
+    To use DynaActionForms with the Struts Validator, specify
+    <code>org.apache.struts.validator.ValidatorActionForm</code>
+    (or your subclass) as the form-bean class.
+    </p>
+
+</section>
+
+<section name="4.3.2 Map-backed ActionForms" href="map_action_form_classes">
+
+    <p>
+    The DynaActionForm classes offer the ability to create ActionForm beans 
+    at initialization time, based on a list of properties enumerated in the 
+    Struts configuration file. 
+    However, many HTML forms are generated dynamically at request time. 
+    Since the properties of these forms' ActionForm beans are not all known 
+    ahead of time, we need a new approach.
+    </p>
+    
+    <p>
+    Struts allows you to make one or more of your ActionForm's properties' 
+    values a Map instead of a traditional atomic object. 
+    You can then store the data from your form's dynamic fields in that Map. 
+    Here is an example of a map-backed ActionForm class:
+    </p>
+    
+<pre><code><![CDATA[public FooForm extends ActionForm {
+
+    private final Map values = new HashMap();
+
+    public void setValue(String key, Object value) {
+        values.put(key, value);
+    }
+
+    public Object getValue(String key) {
+        return values.get(key);
+    }
+
+}
+]]></code></pre>
+
+    <p>
+    In its corresponding JSP page, you can access objects stored in the 
+    values map using a special notation: <code>mapname(keyname)</code>. 
+    The parentheses in the bean property name indicate that:
+    </p>
+    
+    <ul>
+    
+        <li>
+        The bean property named <code>mapname</code> is indexed using Strings
+        (probably backed by a Map), and that 
+        </li>
+
+        <li>
+        Struts should look for get/set methods that take a String key 
+        parameter to find the correct sub-property value. 
+        Struts will, of course, use the <code>keyname</code> value from the 
+        parentheses when it calls the get/set methods.
+        </li>
+    
+    </ul>
+    
+    <p>
+    Here is a simple example:
+    </p>
+
+<pre><code><![CDATA[<html:text property="value(foo)"/>]]></code></pre>
+
+    <p>
+    This will call the <code>getValue</code> method on FooForm with a key 
+    value of "<code>foo</code>" to find the property value. 
+    To create a form with dynamic field names, you could do the following:
+    </p>
+
+<pre><code><![CDATA[
+<% 
+    for (int i = 0; i < 10; i++) {
+        String name = "value(foo-" + i + ")";
+%>
+        <html:text property="<%= name %>"/>
+        <br/>
+<%
+    }
+%>
+]]></code></pre>
+
+    <p>
+    Note that there is nothing special about the name <code>value</code>. 
+    Your map-backed property could instead be named <code>property</code>, 
+    <code>thingy</code>, or any other bean property name you prefer. 
+    You can even have multiple map-backed properties on the same bean.
+    </p>
+    
+    <p>
+    In addition to map-backed properties, you can also create list-backed 
+    properties. 
+    You do so by creating indexed get/set methods on your bean:
+    </p>
+    
+<pre><code><![CDATA[public FooForm extends ActionForm {
+
+    private final List values = new ArrayList();
+
+    public void setValue(int key, Object value) {
+        values.set(key, value);
+    }
+
+    public Object getValue(int key) {
+        return values.get(key);
+    }
+}
+]]></code></pre>
+
+    <p>
+    In your presentation pages, you access individual entries in a list-backed 
+    property by using a different special notation: 
+    <code>listname[index]</code>. 
+    The braces in the bean property name indicate that the bean property named 
+    <code>listname</code> is indexed (probably backed by a List), and that 
+    Struts should look for get/set methods that take an index parameter in 
+    order to find the correct sub-property value.
+    </p>
+
+    <p>
+        While map-backed ActionForms provide you with more flexibility, they do not support the same range of syntax
+        available to conventional or DynaActionForms.
+        You might have difficulty referencing <a href="../faqs/indexedprops.html">indexed or mapped properties</a>
+        using a map-backed ActionForm.
+    </p>
+
+</section>
+
+<section name="4.4 Action Classes" href="action_classes">
+
+    <p>
+    The <code>Action</code> class defines two methods that could be
+    executed depending on your servlet environment:
+    </p>
+
+<pre><code>public ActionForward execute(ActionMapping mapping,
+                     ActionForm form,
+                     ServletRequest request,
+                     ServletResponse response)
+throws Exception;
+
+public ActionForward execute(ActionMapping mapping,
+                     ActionForm form,
+                     HttpServletRequest request,
+                     HttpServletResponse response)
+throws Exception;
+</code></pre>
+
+    <p>
+    Since the majority of Struts projects are focused on building web 
+    applications, most projects will only use the "HttpServletRequest" 
+    version.
+    A non-HTTP execute() method has been provided for applications that are 
+    not specifically geared towards the HTTP protocol.  
+    </p>
+
+    <p>
+    The goal of an <code>Action</code> class is to process a request, via
+    its <code>execute</code> method, and return an <code>ActionForward</code> 
+    object that identifies where control should be forwarded (e.g. a JSP, 
+    Tile definition, Velocity template, or another Action) to provide the 
+    appropriate response.  
+    In the <em>MVC/Model 2</em> design pattern, a typical <code>Action</code> 
+    class will often implement logic like the following in its 
+    <code>execute</code> method:
+    </p>
+    
+    <ul>
+    
+        <li>
+        Validate the current state of the user's session (for example, 
+        checking that the user has successfully logged on).
+        If the <code>Action</code> class finds that no logon exists, the 
+        request can be forwarded to the presentation page that displays the 
+        username and password prompts for logging on.  
+        This could occur because a user tried to enter an application "in the 
+        middle" (say, from a bookmark), or because the session has timed out, 
+        and the servlet container created a new one.
+        </li>
+
+        <li>
+        If validation is not complete, validate the form bean properties as 
+        needed. 
+        If a problem is found, store the appropriate error message keys as a 
+        request attribute, and forward control back to the input form so that 
+        the errors can be corrected.
+        </li>
+
+        <li>
+        Perform the processing required to deal with this request (such as
+        saving a row into a database).  
+        This <em>can</em> be done by logic code embedded within the 
+        <code>Action</code> class itself, <strong>but</strong> should generally be 
+        performed by calling an appropriate method of a business logic bean.
+        </li>
+
+        <li>
+        Update the server-side objects that will be used to create the next
+        page of the user interface (typically request scope or session scope
+        beans, depending on how long you need to keep these items available).
+        </li>
+
+        <li>
+        Return an appropriate <code>ActionForward</code> object that 
+        identifies the presentation page to be used to generate this response, 
+        based on the newly updated beans. 
+        Typically, you will acquire a reference to such an object by calling 
+        <code>findForward</code> on either the <code>ActionMapping</code> 
+        object you received (if you are using a logical name local to this 
+        mapping), or on the controller servlet itself (if you are using a 
+        logical name global to the application).
+        </li>
+    
+    </ul>
+
+    <p>
+    In Struts 1.0, Actions called a <code>perform</code> method instead of 
+    the now-preferred <code>execute</code> method. 
+    These methods use the same parameters and differ only in which exceptions 
+    they throw. 
+    The elder <code>perform</code> method throws <code>SerlvetException</code> 
+    and <code>IOException</code>. 
+    The new <code>execute</code> method simply throws <code>Exception</code>. 
+    The change was to facilitate the Declarative Exception handling feature 
+    introduced in Struts 1.1.
+    </p>
+    
+    <p>
+    The <code>perform</code> method may still be used in Struts 1.1 but is 
+    deprecated.
+    The Struts 1.1 method simply calls the new <code>execute</code> method 
+    and wraps any <code>Exception</code> thrown as a 
+    <code>ServletException</code>.
+    </p>
+
+   </section>
+   
+   <section name="4.4.1 Action Class Design Guidelines" href="action_design_guide">
+
+    <p>
+    Remember the following design guidelines when coding <code>Action</code> 
+    classes:
+    </p>
+
+    <ul>
+    
+        <li>
+        <strong>Write code for a multi-threaded environment</strong> -
+        The controller servlet creates <strong>only one instance of your
+        <code>Action</code> class</strong>, and uses this one instance to service
+        all requests.  
+        Thus, you need to write thread-safe <code>Action</code> classes.
+        Follow the same guidelines you would use to write thread-safe 
+        Servlets.  
+        Here are two general guidelines that will help you write scalable, 
+        thread-safe Action classes:
+        
+        <ul>
+        
+            <li>
+            <strong>Only Use Local Variables</strong> - The most important principle 
+            that aids in thread-safe coding is to use only local variables, 
+            <strong>not instance variables</strong>, in your <code>Action</code> class.  
+            Local variables are created on a stack that is assigned (by your 
+            JVM) to each request thread, so there is no need to worry about 
+            sharing them.  
+            An <code>Action</code> can be factored into several local methods, 
+            so  long as all variables needed are passed as method parameters. 
+            This assures thread safety, as the JVM handles such variables 
+            internally using the call stack which is associated with a single 
+            Thread.
+            </li>
+            
+            <li>
+            <strong>Conserve Resources</strong> - As a general rule, allocating scarce 
+            resources and keeping them across requests from the same user 
+            (in the user's session) can cause scalability problems.  
+            For example, if your application uses JDBC and you  allocate a 
+            separate JDBC connection for every user, you are probably going
+            to run in some scalability issues when your site suddenly shows 
+            up on Slashdot.  
+            You should strive to use pools and release resources (such as 
+            database connections) prior to forwarding control to the 
+            appropriate View component -- even if a bean method you have 
+            called throws an exception.
+            </li>
+            
+        </ul>
+    
+        </li>
+
+        <li>
+        <strong>Don't throw it, catch it!</strong> - Ever used a commercial website only to 
+        have a stack trace or exception thrown in your face after you've already 
+        typed in your credit card number and clicked the purchase button?  
+        Let's just say it doesn't inspire confidence.  
+        Now is your chance to deal with these application errors - in the 
+        <code>Action</code> class.  
+        If your application specific code throws expections you should catch these 
+        exceptions  in your Action class, log them in your application's log 
+        (<code>servlet.log("Error message", exception)</code>) and return the 
+        appropriate ActionForward.
+        </li>
+    
+    </ul>
+
+    <p>
+    It is wise to avoid creating lengthy and complex Action classes.
+    If you start to embed too much logic in the <code>Action</code> class 
+    itself, you will begin to find the <code>Action</code> class hard to 
+    understand, maintain, and impossible to reuse.  
+    Rather than creating overly complex Action classes, it is generally a 
+    good practice to move most of the persistence, and "business logic" to a 
+    separate application layer.  
+    When an Action class becomes lengthy and procedural, it may be a good time 
+    to refactor your application architecture and move some of this logic
+    to another conceptual layer; 
+    otherwise, you may be left with an inflexible application which can only 
+    be accessed in a web-application environment.
+    Struts should be viewed as simply the <strong>foundation</strong> for implementing 
+    MVC in your applications. 
+    Struts provides you with a useful control layer, but it is not a fully 
+    featured platform for building MVC applications, soup to nuts.
+    </p>
+
+    <p>
+    The MailReader example application included with Struts stretches this design
+    principle somewhat, because the business logic itself is embedded in the
+    <code>Action</code> classes. 
+    This should be considered something of a bug in the design of the example,
+    rather than an intrinsic feature of the Struts architecture, or an 
+    approach to be emulated.
+    In order to demonstrate, in simple terms, the different ways Struts can be
+    used, the MailReader application does not always follow best practices.
+    </p>
+      
+</section>
+   
+<section name="4.5 Exception Handler" href="exception_handler">
+
+    <p>
+    You can define an ExceptionHandler to execute when an Action's 
+    <code>execute</code> method throws an Exception.  
+    First, you need to subclass 
+    <code>org.apache.struts.action.ExceptionHandler</code> and override the 
+    <code>execute</code> method.
+    Your <code>execute</code> method should process the Exception and return 
+    an ActionForward object to tell Struts where to forward to next.  
+    Then you configure your handler in struts-config.xml like this:
+    </p>
+    
+<pre><code><![CDATA[<global-exceptions>
+    <exception 
+      key="some.key" 
+      type="java.io.IOException" 
+      handler="com.yourcorp.ExceptionHandler"/>
+</global-exceptions>
+]]></code></pre>
+    
+    <p>
+    This configuration element says that 
+    <code>com.yourcorp.ExceptionHandler.execute</code> will be called when 
+    any IOException is thrown by an Action.  
+    The <code>key</code> is a key into your message resources properties file 
+    that can be used to retrieve an error message.
+    </p>
+    
+    <p>
+    You can override global exception handlers by defining a handler inside an 
+    action definition.
+    </p>
+    
+    <p>
+    A common use of ExceptionHandlers is to configure one for 
+    <code>java.lang.Exception</code> so it's called for any exception and log 
+    the exception to some data store.
+    </p>
+    
+</section>
+
+<section name="4.6 PlugIn Classes" href="plugin_classes">
+
+    <p>
+    The <em>PlugIn</em> interface extends Action and so that applications can
+    easily hook into the ActionServlet lifecycle. 
+    This interface defines two methods, <code>init()</code> and 
+    <code>destroy()</code>, which are called at application startup and 
+    shutdown, respectively. 
+    A common use of a Plugin Action is to configure or load 
+    application-specific data as the web application is starting up.
+    </p>
+    
+    <p>
+    At runtime, any resource setup by <code>init</code> would be accessed by 
+    Actions or business tier classes. 
+    The PlugIn interface allows you to setup resources, but does not provide 
+    any special way to access them. 
+    Most often, the resource would be stored in application context, under
+    a known key, where other components can find it.
+    </p>
+    
+    <p>
+    PlugIns are configured using &lt;plug-in&gt; elements within the
+    Struts configuration file. 
+    See <a href="configuration.html#plugin_config"> PlugIn Configuration</a> 
+    for details.
+    </p>
+
+</section>
+
+<section name="4.7 The ActionMapping Implementation" href="actionmapping">
+
+    <p>
+    In order to operate successfully, the Struts controller servlet needs
+    to know several things about how each request URI should be mapped to an
+    appropriate <code>Action</code> class.  
+    The required knowledge has been encapsulated in a Java class named 
+    <em>ActionMapping</em>, the most important properties are as follows:
+    </p>
+
+    <ul>
+    
+        <li>
+        <code>type</code> - Fully qualified Java class name of the Action 
+        implementation class used by this mapping.
+        </li>
+
+        <li>
+        <code>name</code> - The name of the form bean defined in the config file
+        that this action will use.
+        </li>
+
+        <li>
+        <code>path</code> - The request URI path that is matched to select this
+        mapping.  
+        See below for examples of how matching works and how to use wildcards 
+        to match multiple request URIs.
+        </li>
+
+        <li>
+        <code>unknown</code> - Set to <code>true</code> if this action
+        should be configured as the default for this application, to handle
+        all requests not handled by another action.  
+        Only one action can be defined as a default within a single application.
+        </li>
+
+        <li>
+        <code>validate</code> - Set to <code>true</code> if the 
+        <code>validate</code> method of the action associated with this mapping 
+        should be called.
+        </li>
+
+        <li>
+        <code>forward</code> - The request URI path to which control is passed
+        when this mapping is invoked. 
+        This is an alternative to declaring a <code>type</code> property. 
+        </li>
+
+    </ul>
+
+</section>
+
+<section name="4.8 Writing Action Mappings" href="config">
+
+    <p>
+    How does the controller servlet learn about the mappings you want?
+    It would be possible (but tedious) to write a small Java class that simply
+    instantiated new <code>ActionMapping</code> instances, and called all of
+    the appropriate setter methods.  
+    To make this process easier, Struts uses the Jakarta-Digester component 
+    to parse an XML-based description of the desired mappings and create the 
+    appropriate objects initialized to the appropriate default values.
+    See the <a href="http://jakarta.apache.org/commons">Jakarta Commons 
+    website</a> for more information about the Digester.
+    </p>
+
+    <p>
+    The developer's responsibility is to create an XML file named
+    <code>struts-config.xml</code> and place it in the WEB-INF directory of 
+    your application. 
+    This format of this document is described by the Document Type Definition
+    (DTD) maintained at
+    <a href="http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">
+    http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd</a>.
+    This chapter covers the configuration elements that you will typically 
+    write as part of developing your application.
+    There are several other elements that can be placed in the 
+    struts-config file to customize your application. 
+    See "<a href="configuration.html">Configuring Applications</a>" for more 
+    about the other elements in the Struts configuration file. 
+    </p>
+
+    <p>
+    The controller uses an internal copy of this document to parse the 
+    configuration; an Internet connection is not required for operation.
+    </p>
+
+    <p>
+    The outermost XML element must be <code>&lt;struts-config&gt;</code>. 
+    Inside of the &lt;struts-config&gt; element, there are three important 
+    elements that are used to describe your actions:
+    </p>
+    
+    <ul>
+    
+        <li>
+        <code>&lt;form-beans&gt;</code>
+        </li>
+    
+        <li>
+        <code>&lt;global-forwards&gt;</code>
+        </li>
+    
+        <li>
+        <code>&lt;action-mappings&gt;</code>
+        </li>
+
+    </ul>
+    
+    <p>
+    <code><strong>&lt;form-beans&gt;</strong></code><br />
+    This section contains your form bean definitions.  
+    Form beans are descriptors that are used to create ActionForm instances 
+    at runtime. 
+    You use a &lt;form-bean&gt; element for each form bean, which has the 
+    following important attributes:
+    </p>
+    
+    <ul>
+    
+        <li>
+        <code>name</code>: A unique identifier for this bean, which will be 
+        used to reference it in corresponding action mappings. 
+        Usually, this is also the name of the request or session attribute 
+        under which this form bean will be stored.
+        </li>
+
+        <li>
+        <code>type</code>: The fully-qualified Java classname of the 
+        ActionForm subclass to use with this form bean.
+        </li>
+
+    </ul>
+
+    <p>
+    <strong>&lt;global-forwards&gt;</strong><br />
+    This section contains your global forward definitions.  
+    Forwards are instances of the ActionForward class returned from an 
+    ActionForm's <code>execute</code> method. 
+    These map logical names to specific resources (typically JSPs), allowing 
+    you to change the resource without changing references to it throughout 
+    your application.
+    You use a <code>&lt;forward&gt;</code> element for each forward 
+    definition, which has the following important attributes:
+    </p>
+    
+    <ul>
+    
+        <li>
+        <code>name</code>: The logical name for this forward.  
+        This is used in your ActionForm's <code>execute</code> method to 
+        forward to the next appropriate resource. 
+        Example: homepage
+        </li>
+
+        <li>
+        <code>path</code>: The context relative path to the resource.
+        Example: /index.jsp or /index.do
+        </li>
+
+        <li>
+        <code>redirect</code>: <code>True</code> or <code>false</code> 
+        (default).  
+        Should the ActionServlet redirect to the resource instead of forward?
+        </li>
+
+    </ul>
+    
+    <p>
+    <code><strong>&lt;action-mappings&gt;</strong></code><br />
+    This section contains your action definitions.  
+    You use an <code>&lt;action&gt;</code> element for each of the mappings 
+    you would like to define.  
+    Most action elements will define at least the following attributes:
+    </p>
+
+    <ul>
+
+        <li>
+        <code>path</code>: The application context-relative path to the 
+        action.
+        </li>
+
+        <li>
+        <code>type</code>: The fully qualified java classname of your 
+        Action class.
+        </li>
+
+        <li>
+        <code>name</code>: The name of your 
+        <code>&lt;form-bean&gt;</code> element to use with this action
+        </li>
+
+    </ul>
+
+    <p>Other often-used attributes include:</p>
+
+    <ul>
+    
+        <li>
+        <code>parameter</code>: A general-purpose attribute often used by 
+        "standard" Actions to pass a required property.
+        </li>
+    
+        <li>
+        <code>roles</code>: A comma-delimited list of the user security roles 
+        that can access this mapping.
+        </li>
+    
+    </ul>
+
+    <p>
+    For a complete description of the elements that can be used with the 
+    <code>action</code> element, see the
+    <a href="http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">
+    Struts Configuration DTD</a> and the
+    <a href="../api/org/apache/struts/action/ActionMapping.html">ActionMapping 
+    documentation</a>.
+    </p>
+
+</section>
+
+<section name="4.8.1 ActionMapping Example" href="action_mapping_example">
+
+    <p>
+    Here's a mapping entry based on the MailReader example
+    application. The MailReader application now uses DynaActionForms.
+    But in this example, we'll show a conventinal
+    ActionForm instead, to illustrate the usual workflow.
+    Note that the entries for all the other actions are left out:
+    </p>
+
+<pre><code><![CDATA[<struts-config>
+    <form-beans>
+        <form-bean
+            name="logonForm"
+            type="org.apache.struts.webapp.example.LogonForm" />
+     </form-beans>
+    <global-forwards
+        type="org.apache.struts.action.ActionForward">
+        <forward 
+            name="logon" 
+            path="/logon.jsp"
+            redirect="false" />
+    </global-forwards>
+    <action-mappings>
+        <action
+            path="/logon"
+            type="org.apache.struts.webapp.example.LogonAction"
+            name="logonForm"
+            scope="request"
+            input="/logon.jsp"
+            unknown="false"
+            validate="true" />
+    </action-mappings>
+</struts-config>
+]]></code></pre>
+
+    <p>
+    First the form bean is defined.  
+    A basic bean of class "<code>org.apache.struts.webapp.example.LogonForm</code>"
+    is mapped to the logical name "<code>logonForm</code>". 
+    This name is used as a request attribute name for the form
+    bean.
+    </p>
+
+    <p>
+    The "<code>global-forwards</code>" section is used to create logical name 
+    mappings for commonly used presentation pages.  
+    Each of these forwards is available through a call to your action mapping 
+    instance, i.e. <code>mapping.findForward("logicalName")</code>.
+    </p>
+
+    <p>
+    As you can see, this mapping matches the path <code>/logon</code> 
+    (actually, because the MailReader example application uses extension 
+    mapping, the request URI you specify in a JSP page would end in 
+    <code>/logon.do</code>).
+    When a request that matches this path is received, an instance of the
+    <em>LogonAction</em> class will be created (the first time only) and used.
+    The controller servlet will look for a bean in request scope under key
+    <code>logonForm</code>, creating and saving a bean of the specified class
+    if needed.
+    </p>
+   
+    <p>
+    Optional but very useful are the local "<code>forward</code>" elements. 
+    In the MailReader example application, many actions include a local 
+    "success" and/or "failure" forward as part of an action mapping.
+    </p>
+
+<pre><code><![CDATA[<!-- Edit mail subscription -->
+<action    
+    path="/editSubscription"
+    type="org.apache.struts.webapp.example.EditSubscriptionAction"
+    name="subscriptionForm"
+    scope="request"
+    validate="false">
+    <forward 
+        name="failure" 
+        path="/mainMenu.jsp"/>
+    <forward 
+        name="success" 
+        path="/subscription.jsp"/>
+</action>
+]]></code></pre>
+
+    <p>
+    Using just these two extra properties, the Action classes are almost 
+    totally independent of the actual names of the presentation pages. 
+    The pages can be renamed (for example) during a redesign, with negligible 
+    impact on the Action classes themselves.
+    If the names of the "next" pages were hard coded into the Action classes, 
+    all of these classes would also need to be modified. 
+    Of course, you can define whatever local <code>forward</code> properties 
+    makes sense for your own application.
+    </p>
+
+    <p>
+    The Struts configuration file includes several other elements that you 
+    can use to customize your application. 
+    See "<a href="configuration.html">Configuring Applications</a>" for details.
+    </p>
+
+</section>
+
+<section name="4.9 Using ActionMappings for Pages" href="module_config-use_actions">
+
+    <p>
+    Fronting your pages with ActionMappings is <em>essential</em> when using 
+    application modules, since doing so is the only way you involve the 
+    controller in the request -- and you want to!  
+    The controller puts the application configuration in the request,
+    which makes available all of your module-specific configuration data 
+    (including which message resources you are using, request-processor, 
+    datasources, and so forth).
+    </p>
+    
+    <p>
+    The simplest way to do this is to use the <code>forward</code> property 
+    of the ActionMapping:
+    </p>
+    
+    <pre>&lt;action path="/view" forward="/view.jsp"/></pre>
+
+</section>
+
+<section name="4.10 Using Wildcards in ActionMappings" href="action_mapping_wildcards">
+
+    <p>
+    As a Struts application grows in size, so will the number of action 
+    mappings.  Wildcards can be used to combine similiar mappings into one
+    more generic mapping.  
+    </p>
+    <p>
+    The best way to explain wildcards is to show an example and walk through 
+    how it works.  This example modifies the previous mapping in the <a 
+    href="#action_mapping_example">ActionMapping Example</a> section to use
+    wildcards to match all pages that start with <code>/edit</code>:
+    </p> 
+
+<pre><code><![CDATA[<!-- Generic edit* mapping -->
+<action    
+    path="/edit*"
+    type="org.apache.struts.webapp.example.Edit{1}Action"
+    name="{1}Form"
+    scope="request"
+    validate="false">
+    <forward 
+        name="failure" 
+        path="/mainMenu.jsp"/>
+    <forward 
+        name="success" 
+        path="/{1}.jsp"/>
+</action>
+]]></code></pre>
+
+    <p>
+    The "<code>*</code>" in the path attribute allows the mapping to match the 
+    request URIs <code>/editSubscription</code>, <code>editRegistration</code>,
+    or any other URI that starts with 
+    <code>/edit</code>, however <code>/editSubscription/add</code> would not be 
+    matched.  The part of 
+    the URI matched by the wildcard will then be substituted into various 
+    attributes of the action mapping and its action forwards replacing 
+    <code>{1}</code>.
+    For the rest of the request, Struts will see the action mapping and its 
+    action forwards containing the new values.
+    </p>
+    
+    <p>
+    Wildcard patterns can contain one or more of the following special tokens:
+    </p>
+
+    <table>
+        <tr>
+            <td>
+            <code>*</code>
+            </td>
+            <td>
+            Matches zero or more characters excluding the 
+            slash ('/') character.
+            </td>
+        </tr>       <tr>
+            <td>
+            <code>**</code>
+            </td>
+            <td>
+            Matches zero or more characters including the 
+            slash ('/') character.
+            </td>
+        </tr>       <tr>
+            <td>
+            <code>\character</code>
+            </td>
+            <td>
+            The backslash character is used as an escape
+            sequence.  Thus <code>\*</code> matches the character asterisk 
+            ('*'), and <code>\\</code>
+            matches the character backslash ('\').
+            </td>
+        </tr>
+    </table>    
+
+    <p>
+    In the action mapping and action forwards, the wildcard-matched values can
+    be accessed with the token <code>{N}</code> where <code>N</code>
+    is a number from 1 to 9 indicating
+    which wildcard-matched value to substitute.  The whole request URI can be
+    accessed with the <code>{0}</code> token.
+    </p>
+
+    <p>
+    The action mapping attributes that will accept wildcard-matched strings
+    are:
+    </p>
+
+    <ul>
+        <li><code>type</code></li>
+        <li><code>name</code></li>
+        <li><code>roles</code></li>
+        <li><code>parameter</code></li>
+        <li><code>attribute</code></li>
+        <li><code>forward</code></li>
+        <li><code>include</code></li>
+        <li><code>input</code></li>
+    </ul>
+
+    <p>
+    The action forward attributes that will accept wildcard-matched strings
+    are:
+    </p>
+
+    <ul>
+        <li><code>path</code></li>
+    </ul>
+
+</section>
+
+<section name="4.11 Commons Logging Interface" href="logging">
+    <p>
+    Struts doesn't configure logging itself -- it's all done by
+    <a href="http://jakarta.apache.org/commons/">commons-logging</a> 
+    under the covers. 
+    The default algorithm is a search:
+    </p>
+    
+    <ul>
+    
+        <li>
+        If Log4J is there, use it.
+        </li>
+
+        <li>
+        If JDK 1.4 is there, use it.
+        </li>
+
+        <li>
+        Otherwise, use SimpleLog.
+        </li>
+    
+    </ul>
+    
+    <p>
+    The commons-logging interface is an <em>ultra-thin</em> bridge to many 
+    different logging implementations.  
+    The intent is to remove compile- and run-time dependencies on any 
+    single logging implementation.  
+    For more information about the currently-supported implementations, 
+    please refer to the
+    <a href="http://jakarta.apache.org/commons/logging/api/index.html">
+    the description for the <code>org.apache.commons.logging</code> 
+    package</a>.
+    </p>
+    
+    <p>
+    Because Struts uses commons-logging and, therefore, includes the necessary 
+    JAR files for <strong>you</strong> to use commons-logging, you've probably had the 
+    occasional fleeting thought, <em>"Should I use
+    commons-logging?"</em> 
+    The answer (surprise!) depends on the requirements for your particular 
+    project. 
+    If one of your requirements is the ability to easily change logging 
+    implementations with zero impact on your application, then commons-logging 
+    is a very good option.
+    </p>
+    
+    <p>
+    <em>"Great!  What do I do to get started using commons-logging in my own 
+    code?"</em>
+    </p>
+    
+    <p>
+    Using commons-logging in your own code is very simple - all you need are 
+    two imports and a declaration for a logger.
+    Let's take a look:
+    </p>
+    
+<pre><code>package com.foo;
+// ...
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+...
+public class Foo {
+    // ...
+    private static Log log = LogFactory.getLog(Foo.class);
+    // ...
+    public void setBar(Bar bar) {
+        if (log.isTraceEnabled()) { 
+            log.trace("Setting bar to " + bar);
+        }
+        this.bar = bar;
+    }
+// ...
+}
+</code></pre>
+    
+    <p>
+    The general idea is to instantiate a single logger per class and to
+    use a name for the logger which reflects where it's being used.  The
+    example is constructed with the class itself.  This gives the
+    logger the name of com.foo.Foo.  Doing things this way lets you
+    easily see where the output is coming from, so you can quickly
+    pin-point problem areas.  In addition, you are able to enable/disable
+    logging in a very fine-grained way.
+    </p>
+
+    <p>
+    For examples of using logging in Struts classes, see the
+    Action classes in the Struts MailReader example application.
+    </p>
+
+</section>
+
+<section>
+    <p class="right">
+    Next: <a href="./configuration.html">Configuring Applications</a>
+    </p>
+</section>
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/userGuide/building_model.xml b/build-legacy/core/xdocs/userGuide/building_model.xml
new file mode 100644
index 0000000..f50082c
--- /dev/null
+++ b/build-legacy/core/xdocs/userGuide/building_model.xml
@@ -0,0 +1,279 @@
+<?xml version="1.0"?>
+
+<!--
+// ======================================================================== 78
+-->
+
+<document url="building_model.html">
+
+<properties>
+    <title>The Struts User's Guide - Building Model Components</title>
+</properties>
+
+<body>
+<section name="2. Building Model Components" href="building_model"/>
+
+<section name="2.1 Overview" href="overview">
+
+    <p>
+    Many requirements documents used for building web applications focus on 
+    the <em>View</em>.  
+    However, you should ensure that the processing required for each submitted 
+    request is also clearly defined from the <em>Model's</em> perspective.  
+    In general, the developer of the <em>Model</em> components will be focusing 
+    on the creation of JavaBeans classes that support all of the functional 
+    requirements.  
+    The precise nature of the beans required by a particular application will 
+    vary widely depending on those requirements, but they can generally be
+    classified into several categories discussed below.  
+    However, a brief review of the concept of "scope" as it relates to beans 
+    and JSP is useful first.
+    </p>
+    
+</section>
+
+<section name="2.2 JavaBeans and Scope" href="javabeans">
+
+    <p>
+    Within a web-based application, JavaBeans can be stored in (and accessed
+    from) a number of different collections of "attributes".  
+    Each collection has different rules for the lifetime of that collection, 
+    and the visibility of the beans stored there.  
+    Together, the rules defining lifetime and visibility are called the 
+    <em>scope</em> of those beans.  
+    The JavaServer Pages (JSP) Specification defines scope choices using 
+    the following terms (with the equivalent servlet API concept defined in 
+    parentheses):
+    </p>
+
+    <ul>
+    
+        <li>
+        <strong>page</strong> - Beans that are visible within a single JSP page,
+        for the lifetime of the current request.  
+        (Local variables of the <code>service</code> method)
+        </li>
+
+        <li>
+        <strong>request</strong> - Beans that are visible within a single JSP page,
+        as well as to any page or servlet that is included in this page,
+        or forwarded to by this page.
+        (Request attributes)
+        </li>
+
+        <li>
+        <strong>session</strong> - Beans that are visible to all JSP pages and
+        servlets that participate in a particular user session, across one
+        or more requests.
+        (Session attributes)
+        </li>
+
+        <li>
+        <strong>application</strong> - Beans that are visible to all JSP pages and
+        servlets that are part of a web application.  
+        (Servlet context attributes)
+        </li>
+    
+    </ul>
+
+    <p>
+    It is important to remember that JSP pages and servlets in the same
+    web application share the same sets of bean collections.  
+    For example, a bean stored as a request attribute in a servlet like this:
+    </p>
+
+    <p>
+    <code>MyCart mycart = new MyCart(...);<br />
+    request.setAttribute("cart", mycart);
+    </code>
+    </p>
+
+    <p>
+    is immediately visible to a JSP page which this servlet forwards to,
+    using a standard action tag like this:
+    </p>
+
+    <p>
+    <code>&lt;jsp:useBean id="cart" scope="request"<br />
+    class="com.mycompany.MyApp.MyCart"/&gt;
+    </code>
+    </p>
+
+</section>
+
+<section name="2.3 ActionForm Beans" href="actionform">
+
+    
+    <strong>Note:</strong> While ActionForm beans often have properties that 
+    correspond to properties in your Model beans, the form beans themselves 
+    should be considered a Controller component. 
+    As such, they are able to transfer data between the Model and View layers.
+    
+
+    <p>
+    The Struts framework generally assumes that you have defined an
+    <code>ActionForm</code> bean (that is, a Java class extending the
+    <code>ActionForm</code> class) for the input forms in your
+    application. 
+    <code>ActionForm</code> beans are sometimes just called "form beans". 
+    These may be finely-grained objects, so that there is one
+    bean for each form, or coarsely-grained so that one bean serves
+    several forms, or even an entire application.
+    </p>
+
+    <p>
+    If you declare such beans in your Struts
+    configuration file (see "<a href="building_controller.html#config">
+    Building the Controller Components</a>"), the Struts  controller servlet
+    will automatically perform the following services for you, before
+    invoking the appropriate <code>Action</code> method:
+    </p>
+
+    <ul>
+    
+        <li>
+        Check for an instance of a bean of the appropriate class, under the appropriate key,
+        in the appropriate scope (request or session).
+        </li>
+
+        <li>
+        If there is no such bean instance available, a new one is
+        automatically created and added to the appropriate scope (request or session).
+        </li>
+
+        <li>
+        For every request parameter whose name corresponds to the name
+        of a property in the bean, the corresponding setter method will
+        be called.  This operates in a manner similar to the standard
+        JSP action <code>&lt;jsp:setProperty&gt;</code> when you use the
+        asterisk wildcard to select all properties.
+        </li>
+
+        <li>
+        The updated <code>ActionForm</code> bean will be passed to the
+        <code>execute</code> method of an <code>Action</code> class
+        [<code>org.apache.struts.Action</code>], so that the values can
+        be made available to your system state and business logic beans.
+        </li>
+    
+    </ul>
+
+    <p>
+    For more about coding <code>Actions</code> and <code>ActionForm</code>
+    beans, see the "<a href="building_controller.html">Building
+    Controller Components</a>" chapter.
+    </p>
+
+    <p>
+    You should note that a "form", in the sense discussed here, does not
+    necessarily correspond to a single JSP page in the user interface.  
+    It is common in many applications to have a "form" (from the user's 
+    perspective) that extends over multiple pages. 
+    Think, for example, of the wizard style user interface that is commonly 
+    used when installing new applications.  
+    Struts encourages you to define a single <code>ActionForm</code> bean that 
+    contains properties for all of the fields, no matter which page the field 
+    is actually displayed on. 
+    Likewise, the various pages of the same form should all be submitted to 
+    the same Action Class. 
+    If you follow these suggestions, the page designers can rearrange the 
+    fields among the various pages, often without requiring changes to the 
+    processing logic.
+    </p>
+
+    <p>
+    Smaller applications may only need a single ActionForm to service all of
+    its input forms. 
+    Others applications might use a single ActionForm for each major subsystem 
+    of the application. 
+    Some teams might prefer to have a separate ActionForm class for each 
+    distinct input form or workflow. 
+    How many or how few ActionForms to use is entirely up to you. 
+    The framework doesn't care.
+    </p>
+
+</section>
+
+<section name="2.4 System State Beans" href="system_state">
+
+    <p>
+    The actual state of a system is normally represented as a set of one or
+    more JavaBeans classes, whose properties define the current state.  
+    A shopping cart system, for example, will include a bean that represents 
+    the cart being maintained for each individual shopper, and will (among 
+    other things) include the set of items that the shopper has currently 
+    selected for purchase.  
+    Separately, the system will also include different beans for the user's 
+    profile information (including their credit card and ship-to addresses), 
+    as well as the catalog of available items and their current inventory 
+    levels.
+    </p>
+
+    <p>
+    For small scale systems, or for state information that need not be kept
+    for a long period of time, a set of system state beans may contain all the
+    knowledge that the system ever has of these particular details.  
+    Or, as is often the case, the system state beans will represent 
+    information that is stored permanently in some external database (such as 
+    a <code>CustomerBean</code> object that corresponds to a particular row in 
+    the CUSTOMERS table), and are created or removed from the server's memory 
+    as needed.  
+    Entity Enterprise JavaBeans are also used for this purpose in large scale 
+    applications.
+    </p>
+
+</section>
+
+<section name="2.5 Business Logic Beans" href="business_logic">
+
+    <p>
+    You should encapsulate the functional logic of your application as
+    method calls on JavaBeans designed for this purpose.  
+    These methods may be part of the same classes used for the system state 
+    beans, or they may be in separate classes dedicated to performing the 
+    logic.  
+    In the latter case, you will usually need to pass the system state beans 
+    to be manipulated to these methods as arguments.
+    </p>
+
+    <p>
+    For maximum code re-use, business logic beans should be designed and
+    implemented so that they do <strong>not</strong> know they are being executed in a
+    web application environment.  
+    If you find yourself having to import a <code>javax.servlet.*</code> class 
+    in your bean, you are tying this business logic to the web application 
+    environment.  
+    Consider rearranging things so that your <code>Action</code> classes (part 
+    of the Controller role, as described below) translate all required 
+    information from the HTTP request being processed into property setter 
+    calls on your business logic beans, after which a call to an 
+    <code>execute</code> method can be made.  
+    Such a business logic class can be reused in environments other than the 
+    web application for which they were initially constructed.
+    </p>
+
+    <p>
+    Depending on the complexity and scope of your application, business logic
+    beans might be ordinary JavaBeans that interact with system state beans
+    passed as arguments, or ordinary JavaBeans that access a database using
+    JDBC calls.  
+    For larger applications, these beans will often be stateful or stateless 
+    Enterprise JavaBeans (EJBs) instead.
+    </p>
+    
+    <p>
+    For more about using a database with your application, see the 
+    <a href="../faqs/database.html">Accessing a Database HowTo</a>.
+    </p>
+
+</section>
+
+<section>
+    <p class="right">
+    Next: <a href="building_view.html">Building View Components</a>
+    </p>
+</section>
+
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/userGuide/building_view.xml b/build-legacy/core/xdocs/userGuide/building_view.xml
new file mode 100644
index 0000000..9e81c35
--- /dev/null
+++ b/build-legacy/core/xdocs/userGuide/building_view.xml
@@ -0,0 +1,896 @@
+<?xml version="1.0"?>
+<document url="building_view.html">
+
+<!--
+// ======================================================================== 78
+-->
+
+<properties>
+    <title>The Struts User's Guide - Building View Components</title>
+</properties>
+
+<body>
+<section name="3. Building View Components" href="building_view"/>
+
+<section name="3.1 Overview" href="overview">
+
+    <p>
+    This chapter focuses on the task of building the <em>View</em> components
+    for use with the Struts framework. 
+    Many applications rely on JavaServer Pages (JSP) technology to create the 
+    presentation layer. 
+    The Struts distribution includes a comprehensive JSP tag library that 
+    provides support for building internationalized applications, as well as 
+    for interacting with input forms.
+    Several other topics related to the View components are briefly discussed.
+    </p>
+
+</section>
+
+<section name="3.2 Internationalized Messages" href="i18n">
+
+    <p>
+    A few years ago, application developers could count on having to support
+    only residents of their own country, who are used to only one (or 
+    sometimes two) languages, and one way to represent numeric quantities like 
+    dates, numbers, and monetary values.  
+    However, the explosion of application development based on web 
+    technologies, as well as the deployment of such applications on the 
+    Internet and other broadly accessible networks, have rendered national 
+    boundaries invisible in many cases.  
+    This has translated (if you will pardon the pun) into a need for 
+    applications to support <em>internationalization</em> (often called "i18n" 
+    because 18 is the number of letters in between the "i" and the "n") and 
+    <em>localization</em>.
+    </p>
+
+    <p>
+    Struts builds upon the standard classes available on the Java platform to
+    build internationalized and localized applications. 
+    The key concepts to become familiar with are:
+    </p>
+
+    <ul>
+    
+        <li>
+        <a href="http://java.sun.com/j2se/1.4.1/docs/api/java/util/Locale.html">
+        <strong>Locale</strong></a> - The fundamental Java class that supports 
+        internationalization is <code>Locale</code>.  
+        Each <code>Locale</code> represents a particular choice of country and 
+        language (plus an optional language variant), and also a set of 
+        formatting assumptions for things like numbers and dates.
+        </li>
+        
+        <li>
+        <a href="http://java.sun.com/j2se/1.4.1/docs/api/java/util/ResourceBundle.html">
+        <strong>ResourceBundle</strong></a> - The <code>java.util.ResourceBundle</code> 
+        class provides the fundamental tools for supporting messages in 
+        multiple languages.  
+        See the Javadocs for the <code>ResourceBundle</code> class, and the 
+        information on Internationalization in the documentation bundle for your 
+        JDK release, for more information.
+        </li>
+        
+        <li>
+        <a href="http://java.sun.com/j2se/1.4.1/docs/api/java/util/PropertyResourceBundle.html">
+        <strong>PropertyResourceBundle</strong></a> - One of the standard 
+        implementations of <code>ResourceBundle</code> allows you to define 
+        resources using  the same "name=value" syntax used to initialize 
+        properties files.  
+        This is very convenient for preparing resource bundles with messages 
+        that are used in a web application, because these messages are 
+        generally text oriented.
+        </li>
+        
+        <li>
+        <a href="http://java.sun.com/j2se/1.4.1/docs/api/java/text/MessageFormat.html">
+        <strong>MessageFormat</strong></a> - The <code>java.text.MessageFormat</code> 
+        class allows you to replace portions of a message string (in this 
+        case, one retrieved from a resource bundle) with arguments specified 
+        at run time.  
+        This is useful in cases where you are creating a sentence, but the 
+        words would appear in a different order in different languages.
+        The placeholder string <code>{0}</code> in the message is replaced by
+        the first runtime argument, <code>{1}</code> is replaced by the 
+        second argument, and so on.
+        </li>
+        
+        <li>
+        <a href="../api/org/apache/struts/util/MessageResources.html">
+        <strong>MessageResources</strong></a> - The Struts class 
+        <code>org.apache.struts.util.MessageResources</code> lets you treat
+        a set of resource bundles like a database, and allows you to request
+        a particular message string for a particular Locale (normally one
+        associated with the current user) instead of for the default Locale
+        the server itself is running in.
+        </li>
+        
+    </ul>
+
+    <p>
+    Please note that the i18n support in a framework like Struts is limited to 
+    the <strong>presentation</strong> of internationalized text and images to the user.
+    Support for Locale specific <strong>input methods</strong> (used with languages
+    such as Japanese, Chinese, and Korean) is left up to the client device, 
+    whichis usually a web browser.
+    </p>
+
+    <p>
+    For an internationalized application, follow the steps described in
+    the Internationalization document in the JDK documentation bundle for your
+    platform to create a properties file containing the messages for each
+    language.  
+    An example will illustrate this further:
+    </p>
+
+    <p>
+    Assume that your source code is created in package
+    <code>com.mycompany.mypackage</code>, so it is stored in a directory
+    (relative to your source directory) named
+    <code>com/mycompany/mypackage</code>.  
+    To create a resource bundle called
+    <code>com.mycompany.mypackage.MyApplication</code>, you would create the
+    following files in the <code>com/mycompany/mypackage</code> directory:
+    </p>
+
+    <ul>
+
+        <li>
+        <strong>MyApplication.properties</strong> - Contains the messages in the default
+        language for your server.  
+        If your default language is English, you might have an entry like 
+        this: <code>prompt.hello=Hello</code>
+        </li>
+
+        <li>
+        <strong>MyApplication_xx.properties</strong> - Contains the same messages in the
+        language whose ISO language code is "xx" (See the
+        <a href="http://java.sun.com/j2se/1.4.1/docs/api/java/util/ResourceBundle.html">
+        ResourceBundle Javadoc</a> page for a link to the current list).  
+        For a French version of the message shown above, you would have this 
+        entry: <code>prompt.hello=Bonjour</code>
+        You can have resource bundle files for as many languages as you need.
+        </li>
+
+    </ul>
+
+    <p>
+    When you configure the controller servlet in the web application
+    deployment descriptor, one of the things you will need to define in
+    an initialization parameter is the base name of the resource bundle
+    for the application.  
+    In the case described above, it would be 
+    <code>com.mycompany.mypackage.MyApplication</code>.
+    </p>
+
+<pre><code><![CDATA[
+<servlet>
+<servlet-name>action</servlet-name>
+<servlet-class>
+org.apache.struts.action.ActionServlet
+</servlet-class>
+<init-param>
+<param-name>application</param-name>
+<param-value>
+    com.mycompany.mypackage.MyResources
+</param-value>
+</init-param>
+<!-- ... -->
+</servlet>
+]]></code></pre>
+
+    <p>
+    The important thing is for the resource bundle to be found on the
+    class path for your application. 
+    Another approach is to store the <code>MyResources.properties</code> 
+    file in your application's <code>classes</code> folder. 
+    You can then simply specify "myResources" as the application value. 
+    Just be careful it is not deleted if your build script deletes 
+    classes as part of a "clean" target.
+    </p>
+
+    <p>
+    If it does, here is an Ant task to run when compiling your application
+    that copies the contents of a <code>src/conf</code>
+    directory to the <code>classes</code> directory:
+    </p>
+
+<pre><code><![CDATA[
+<!-- Copy any configuration files -->
+<copy todir="classes">
+<fileset dir="src/conf"/>
+</copy>
+]]></code></pre>
+
+</section>
+
+<section name="3.3 Forms and FormBean Interactions" href="form_beans">
+
+<p>
+    <strong>Note:</strong> While the examples given here use JSP and custom tags,
+    the ActionForm beans and the other Struts controller components are
+    View neutral. 
+    Struts can be used with Velocity Templates, XSL, and any other 
+    presentation technology that can be rendered via a Java servlet. 
+</p>
+
+    <p>
+    At one time or another, most web developers have built forms using
+    the standard capabilities of HTML, such as the <code>&lt;input&gt;</code>
+    tag.  
+    Users have come to expect interactive applications to have certain
+    behaviors, and one of these expectations relates to error handling -- if
+    the user makes an error, the application should allow them to fix just 
+    what needs to be changed -- without having to re-enter any of the rest 
+    of the information on the current page or form.
+    </p>
+
+    <p>
+    Fulfilling this expectation is tedious and cumbersome when coding with
+    standard HTML and JSP pages.  
+    For example, an input element for a <code>username</code> field might 
+    look like this (in JSP):
+    </p>
+   
+<pre><code><![CDATA[
+<input type="text" name="username"
+value="<%= loginBean.getUsername() >"/>
+]]></code></pre>
+
+    <p>
+    which is difficult to type correctly, confuses HTML developers who are
+    not knowledgeable about programming concepts, and can cause problems with
+    HTML editors.  
+    Instead, Struts provides a comprehensive facility for building forms, 
+    based on the Custom Tag Library facility of JSP 1.1.
+    The case above would be rendered like this using Struts:
+    </p>
+
+<pre><code><![CDATA[
+<html:text property="username"/>;
+]]></code></pre>
+
+    <p>
+    with no need to explicitly refer to the JavaBean from which the initial
+    value is retrieved.  That is handled automatically by the JSP tag, using
+    facilities provided by the framework.
+    </p>
+
+    <p>
+    HTML forms are sometimes used to upload other files. 
+    Most browsers support this through a &lt;input type="file"&gt; element, 
+    that generates a file browse button, but it's up to the developer to 
+    handle the incoming files. 
+    Struts handles these "multipart" forms in a way identical to building 
+    normal forms. 
+    </p>
+    
+    <p>
+    For an example of using Struts to create a simple login form, 
+    see the "<a href="../faqs/actionForm.html">
+    Buiding an ActionForm Howto</a>".
+    </p>
+
+</section>
+
+
+<section name="3.3.1 Indexed &amp; Mapped Properties" href="indexed">
+
+    <p>
+    Property references in JSP pages using the Struts framework can reference
+    Java Bean properties as described in the JavaBeans specification. 
+    Most of these references refer to "scalar" bean properties, referring to 
+    primitive or single Object properties.  
+    However, Struts, along with the Jakarta Commons Beanutils library, allow 
+    you to use property references which refer to individual items in an array, 
+    collection, or map, which are represented by bean methods using 
+    well-defined naming and signature schemes.
+    </p>
+
+<p>
+ Documentation on the Beanutils package can be found at 
+ <a href="http://jakarta.apache.org/commons/beanutils/api/index.html">
+ http://jakarta.apache.org/commons/beanutils/api/index.html</a>.
+ More information about using indexed and mapped properties in Struts can
+ be found in the FAQ describing <a
+ href="../faqs/indexedprops.html"><em>Indexed Properties, Mapped Properties,
+ and Indexed Tags</em></a>.
+</p>
+</section>
+
+<section name="3.3.2 Input Field Types Supported" href="form_input">
+
+    <p>
+    Struts defines HTML tags for all of the following types of input fields,
+    with hyperlinks to the corresponding reference information.
+    </p>
+
+    <ul>
+        
+        <li>
+        <a href="struts-html.html#checkbox">checkboxes</a>
+        </li>
+        
+        <li>
+        <a href="struts-html.html#hidden">hidden</a> fields
+        </li>
+        
+        <li>
+        <a href="struts-html.html#password">password</a> input fields
+        </li>
+        
+        <li>
+        <a href="struts-html.html#radio">radio</a> buttons
+        </li>
+        
+        <li>
+        <a href="struts-html.html#reset">reset</a> buttons
+        </li>
+        
+        <li>
+        <a href="struts-html.html#select">select</a> lists with embedded 
+        option or options items
+        </li>
+        
+        <li>
+        <a href="struts-html.html#option">option</a>
+        </li>
+        
+        <li>
+        <a href="struts-html.html#options">options</a>
+        </li>
+        
+        <li>
+        <a href="struts-html.html#submit">submit</a> buttons
+        </li>
+        
+        <li>
+        <a href="struts-html.html#text">text</a> input fields
+        </li>
+        
+        <li>
+        <a href="struts-html.html#textarea">textareas</a>
+        </li>
+        
+    </ul>
+
+    <p>
+    In every
+    case, a field tag must be nested within a <code>form</code> tag, so that
+    the field knows what bean to use for initializing displayed values.
+    </p>
+
+</section>
+
+<section name="3.3.3 Other Useful Presentation Tags" href="presentation_tags">
+
+    <p>
+    There are several tags useful for creating presentations, consult the 
+    documentation on each specific tag library, along with the Tag Developers 
+    Guides, for more information:
+    </p>
+
+    <ul>
+
+    <li>
+    [logic] <a href="struts-logic.html#iterate">iterate</a> repeats its 
+    tag body once for each element of a specified collection (which can be an 
+    Enumeration, a Hashtable, a Vector, or an array of objects).
+    </li>
+    
+    <li>
+    [logic] <a href="struts-logic.html#present">present</a> depending on 
+    which  attribute is specified, this tag checks the current request, and 
+    evaluates the nested body content of this tag only if the specified value 
+    is present. 
+    Only one of the attributes may be used in one occurrence of this tag, 
+    unless you use the property attribute, in which case the name attribute 
+    is also required. 
+    The attributes include cookie, header, name, parameter, property, role, 
+    scope, and user.
+    </li>
+
+    <li>
+    [logic] <a href="struts-logic.html#notPresent">notPresent</a> the 
+    companion tag to present, notPresent provides the same functionality when 
+    the specified attribute is not present.
+    </li>
+    
+    <li>
+    [html] <a href="struts-html.html#link">link</a> generates a HTML 
+    &lt;a&gt; element as an anchor definition or a hyperlink to the specified 
+    URL, and automatically applies URL encoding to maintain session state in 
+    the absence of cookie support.
+    </li>
+    
+    <li>
+    [html] <a href="struts-html.html#img">img</a> generates a HTML 
+    &lt;img&gt; element with the ability to dynamically modify the URLs 
+    specified by the "src" and "lowsrc" attributes in the same manner that 
+    &lt;html:link> can.
+    </li>
+    
+    <li>
+    [bean] <a href="struts-bean.html#parameter">parameter</a> 
+    retrieves the value of the specified request parameter, and defines the 
+    result as a page scope attribute of type String or String[].
+    </li>
+    
+    </ul>
+
+</section>
+
+<section name="3.3.4 Automatic Form Validation" href="form_validation">
+
+    <p>
+    In addition to the form and bean interactions described above, Struts
+    offers an additional facility to validate the input fields it has received.
+    To utilize this feature, override the following method in your ActionForm
+    class:
+    </p>
+
+<pre><code><![CDATA[
+validate(ActionMapping mapping,
+HttpServletRequest request);
+]]></code></pre>
+
+    <p>
+    The <code>validate</code> method is called by the controller servlet after
+    the  bean properties have been populated, but before the corresponding 
+    action class's <code>execute</code> method is invoked. 
+    The <code>validate</code> method has the following options:
+    </p>
+
+    <ul>
+
+        <li>
+        Perform the appropriate validations and find no problems -- Return
+        either <code>null</code> or a zero-length ActionErrors instance, 
+        and the controller servlet will proceed to call the 
+        <code>perform</code> method of the appropriate <code>Action</code> class.
+        </li>
+
+        <li>
+        Perform the appropriate validations and find problems -- Return an 
+        ActionErrors instance containing <code>ActionError</code>'s, which 
+        are classes that contain the error message keys (into the 
+        application's <code>MessageResources</code> bundle) that should be 
+        displayed. 
+        The controller servlet will store this array as a request attribute 
+        suitable for use by the <code>&lt;html:errors&gt;</code> tag, and 
+        will forward control back to the input form (identified by the 
+        <code>input</code> property for this <code>ActionMapping</code>).
+        </li>
+        
+    </ul>
+
+    <p>
+    As mentioned earlier, this feature is entirely optional.  
+    The default implementation of the <code>validate</code> method returns 
+    <code>null</code>, and the controller servlet will assume that any 
+    required validation is done by the action class.
+    </p>
+    
+    <p>
+    One common approach is to perform simple, prima facia validations using 
+    the ActionForm <code>validate</code> method, and then handle the 
+    "business logic" validation from the Action.
+    </p>
+
+    <p>
+    The Struts Validator, covered in the next section, may be used to easily 
+    validate ActionForms.
+    </p>
+    
+</section>
+
+<section name="3.3.5 The Struts Validator" href="validator">
+
+    <p>
+    Configuring the Validator to perform form validation is easy.
+    </p>
+    <ol>
+    
+    <li>
+    The ActionForm bean must extend ValidatorForm
+    </li>
+    <li>
+    The form's JSP must include the 
+    <a href="struts-html.html">&lt;html:javascript&gt;</a> tag for client 
+    side validation.
+    </li>
+    <li>
+    You must define the validation rules in an xml file like this:
+    
+<pre><code><![CDATA[
+<form-validation>
+<formset>             
+<form name="logonForm">
+  <field property="username" depends="required">
+    <msg name="required" key="error.username"/>
+  </field>    
+</form>        
+</formset>   
+</form-validation>
+]]></code></pre>
+The msg element points to the message resource key to use when generating the error message.
+</li>
+<li>Lastly, you must enable the ValidatorPlugin in the struts-config.xml file like this:
+<pre><code><![CDATA[
+<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
+<set-property 
+property="pathnames" 
+value="/WEB-INF/validator-rules.xml, 
+    /WEB-INF/validation.xml"/>
+</plug-in>
+]]></code></pre>
+
+        </li>
+    </ol>
+    
+    <p>
+    <strong>Note:</strong> If your required form property is one of the Java object representations of 
+    primitive types (ie. java.lang.Integer), you must set the ActionServlet's convertNull init.
+    parameter to true.  Failing to do this will result in the required validation not being performed
+    on that field because it will default to 0.
+    </p>
+    
+    <p>
+    For more about the Struts Validator, see the 
+    <a href="./dev_validator.html">Developers Guide</a>.
+    </p>
+    
+</section>
+
+<section name="3.4 Other Presentation Techniques" href="other_presentations">
+
+    <p>
+    Although the look and feel of your application can be completely
+    constructed based on the standard capabilities of JSP and the Struts
+    custom tag library, you should consider employing other techniques that
+    will improve component reuse, reduce maintenance efforts, and/or reduce
+    errors.  
+    Several options are discussed in the following sections.
+    </p>
+  
+</section>
+
+<section name="3.4.1 Application-Specific Custom Tags" href="custom_tags">
+
+    <p>
+    Beyond using the custom tags provided by the Struts library, it is easy
+    to create tags that are specific to the application you are building, to
+    assist in creating the user interface.  The MailReader example application included with
+    Struts illustrates this principle by creating the following tags unique to
+    the implementation of this application:
+    </p>
+
+    <ul>
+    <li><strong>checkLogon</strong> - Checks for the existence of a particular session
+    object, and forwards control to the logon page if it is missing.  This is
+    used to catch cases where a user has bookmarked a page in the middle of
+    your application and tries to bypass logging on, or if the user's session
+    has been timed out. (Note that there are better ways to authenticate users; the
+    checkLogon tag is simply meant to demonstrate writing your own custom tags.) </li>
+    <li><strong>linkSubscription</strong> - Generates a hyperlink to a details page
+    for a Subscription, which passes the required primary key values as
+    request attributes.  This is used when listing the subscriptions associated
+    with a user, and providing links to edit or delete them.</li>
+    <li><strong>linkUser</strong> - Generates a hyperlink to a details page
+    for a User, which passes the required primary key values as
+    request attributes.</li>
+    </ul>
+
+    <p>
+    The source code for these tags is in the <code>src/example</code> directory,
+    in package <code>org.apache.struts.example</code>, along with the other Java
+    classes that are used in this application.
+    </p>
+</section>
+
+<section name="3.4.2 Page Composition With Includes" href="includes">
+
+    <p>
+    Creating the entire presentation of a page in one JSP file (with custom
+    tags and beans to access the required dynamic data) is a very common 
+    design approach, and was employed in the example application included 
+    with Struts.
+    However, many applications require the display of multiple logically 
+    distinct portions of your application together on a single page.
+    </p>
+
+    <p>
+    For example, a portal application might have some or all of the following
+    functional capabilities available on the portal's "home" page:
+    </p>
+
+    <ul>
+    
+        <li>
+        Access to a search engine for this portal.
+        </li>
+
+        <li>
+        One or more "news feed" displays, with the topics of interest 
+        customizedfrom the user's registration profile.
+        </li>
+
+        <li>
+        Access to discussion topics related to this portal.
+        </li>
+
+        <li>
+        A "mail waiting" indicator if your portal provides free email
+        accounts.
+        </li>
+    
+    </ul>
+
+    <p>
+    The development of the various segments of this site is easier if you
+    can divide up the work, and assign different developers to the different
+    segments.  
+    Then, you can use the <em>include</em> capability of JavaServer Pages
+    technology to combine the results into a single result page, or use the 
+    include tag provided with Struts.  
+    There are three types of <em>include</em> available, depending on when you w
+    ant the combination of output to occur:
+    </p>
+
+    <ul>
+    
+        <li>
+        An <code>&lt;%@ include file="xxxxx" %&gt;</code> directive can 
+        include a file that contains Java code or JSP tags. 
+        The code in the included file can even reference variables declared 
+        earlier in the outer jsp page. 
+        The code is inlined into the other JavaServer Page before it is 
+        compiled so it can definitely contain more than just HTML.
+        </li>
+
+        <li>
+        The include <em>action</em> (<code>&lt;jsp:include page="xxxxx"
+        flush="true" /&gt;</code>) is processed at request time, and is 
+        handled transparently by the server.  
+        Among other things, that means you can conditionally perform the 
+        include by nesting it within a tag like 
+        <a href="struts-logic.html#equal">equal</a> by using it's
+        parameter attribute.
+        </li>
+
+        <li>
+        The <a href="struts-bean.html#include">bean:include</a> 
+        tag takes either a an argument "forward" representing a logical name 
+        mapped to the jsp to include, or the "id" argument, which represents a 
+        page context String variable to print out to the jsp page.
+        </li>
+    
+    </ul>
+
+</section>
+
+<section name="3.4.3 Page Composition With Tiles" href="Tiles">
+
+    <p>
+    Tiles is a powerful templating library that allows you to construct views 
+    by combining various "tiles".  
+    Here's a quick setup guide:
+    </p>
+
+    <ol>
+        <li>
+        Create a /layout/layout.jsp file that contains your app's common look and 
+        feel:
+    
+<pre><code><![CDATA[
+<html>
+<body>
+<tiles:insert attribute="body"/>
+</body>
+</html>
+]]></code></pre>
+        </li>
+        
+        <li>
+    Create your /index.jsp homepage file:
+    
+<pre><code><![CDATA[
+<h1>This is my homepage</h1>
+]]></code></pre>
+
+        </li>
+
+        <li>
+        Create a /WEB-INF/tiles-defs.xml file that looks like this:
+
+<pre><code><![CDATA[
+<tiles-definitions>
+<definition 
+    name="layout" 
+    path="/layout/layout.jsp">
+    <put name="body" value=""/>
+</definition>
+<definition name="homepage" extends="layout">
+    <put 
+        name="body" 
+        value="/index.jsp"/>
+</definition>
+<tiles-definitions>
+]]></code></pre>
+        </li>
+
+        <li>
+        Setup the TilesPlugin in the struts-config.xml file:
+        
+<pre><code><![CDATA[
+<plug-in 
+    className="org.apache.struts.tiles.TilesPlugin">
+    <set-property 
+        property="definitions-config" 
+        value="/WEB-INF/tiles-defs.xml"/>
+</plug-in>
+]]></code></pre>
+        </li>
+        
+        <li>
+        Setup an action mapping in struts-config.xml to point to your 
+        homepage tile:
+
+<pre><code><![CDATA[
+<action 
+path="/index"
+type="org.apache.struts.actions.ForwardAction"
+parameter="homepage"/>
+]]></code></pre>
+        </li>
+        </ol>
+
+        <p>
+        The TilesPlugin configures a special RequestProcessor that determines 
+        if the requested view is a tile and processes it accordingly.  
+        Note that we made the homepage tile extend our root layout tile and 
+        changed the body attribute.  
+        Tiles inserts the file named in the body attribute into the main 
+        layout.
+        </p>
+
+        <p>
+        See the tiles-documentation webapp for in-depth examples.
+        </p>
+  
+  </section>
+
+  <section name="3.4.4 Image Rendering Components" href="image_rendering">
+
+        <p>
+        Some applications require dynamically generated images, like the 
+        price charts on a stock reporting site.  
+        Two different approaches are commonly  used to meet these 
+        requirements:
+        </p>
+
+    <ul>
+  
+        <li>
+        Render a hyperlink with a URL that executes a servlet request.  
+        The servlet will use a graphics library to render the graphical image,
+        set the content type appropriately (such as to 
+        <code>image/gif</code>), and send back the bytes of that image to the 
+        browser, which will display them just as if it had received a static 
+        file.
+        </li>
+
+        <li>
+        Render the HTML code necessary to download a Java applet that 
+        creates the required graph.  
+        You can configure the graph by setting appropriate initialization 
+        parameters for the applet in the rendered code, or you can have the 
+        applet make its own connection to the server to receive
+        these parameters.
+        </li>
+        
+    </ul>
+    
+  </section>
+
+  <section name="3.4.5 Rendering Text" href="text_rendering">
+
+    <p>
+    Some applications require dynamically generated text or markup,
+    such as XML. 
+    If a complete page is being rendered, and can be output using a 
+    PrintWriter, this is very easy to do from an Action:
+    </p>
+
+<pre><code><![CDATA[
+response.setContentType("text/plain"); // or text/xml
+PrintWriter writer = response.getWriter();
+// use writer to render text
+return(null);
+]]></code></pre>
+
+</section>
+
+    <section name="3.4.6 The Struts-EL Tag Library" href="struts-el">
+    
+    <p>
+    The <strong>Struts-EL</strong> tag library is a contributed library in
+    the Struts distribution.  
+    It represents an integration of the Struts tag library with the JavaServer 
+    Pages Standard Tag Library, or at least the "expression evaluation" 
+    engine that is used by the JSTL.
+    </p>
+
+    <p>
+    The base Struts tag library contains tags which rely on the evaluation
+    of "rtexprvalue"s (runtime scriptlet expressions) to evaluate dynamic
+    attribute values.  For instance, to print a message from a properties
+    file based on a resource key, you would use the
+    <code>bean:write</code> tag, perhaps like this:</p>
+    <pre><code>
+    <![CDATA[<bean:message key='<%= stringvar %>'/>]]>
+    </code></pre>
+
+    <p>
+    This assumes that <code>stringvar</code> exists as a JSP scripting
+    variable.  If you're using the <strong>Struts-EL</strong> library, the
+    reference looks very similar, but slightly different, like this:</p>
+    <pre><code>
+    <![CDATA[<bean-el:message key="${stringvar}"/>]]>
+    </code></pre>
+
+    <p>
+    If you want to know how to properly use the <strong>Struts-EL</strong>
+    tag library, there are two important things you need to know:
+    </p>
+    
+    <ul>
+    
+        <li>
+        The Struts tag library
+        </li>
+
+        <li>
+        The JavaServer Pages Standard tag library
+        </li>
+
+    </ul>
+
+
+    <p>
+    Once you understand how to use these two, consider Struts tag
+    attribute values being evaluated the same way the JSTL tag attribute
+    values are.  
+    Past that, there is very little else you need to know to effectively use 
+    the <strong>Struts-EL</strong> tag library.
+    </p>
+    
+    <p>
+    Although the <strong>Struts-EL</strong> tag library is a direct "port"
+    of the tags from the Struts tag library, not all of the tags in the
+    Struts tag library were implemented in the <strong>Struts-EL</strong>
+    tag library.  
+    This was the case if it was clear that the functionality of a particular 
+    Struts tag could be entirely fulfilled by a tag in the JSTL.  
+    It is assumed that developers will want to use the 
+    <strong>Struts-EL</strong> tag library along with the JSTL, so it is 
+    reasonable to assume that they will use tags from the JSTL if they
+    fill their needs.
+    </p>
+
+    <p>
+    For more see, <a href="../faqs/struts-el.html">Struts-El Extension</a> in the FAQ/HOWTO section.
+    </p>
+
+</section>
+
+<section>
+    <p class="right">
+    Next: <a href="building_controller.html">Building Controller 
+    Components</a>
+    </p>
+</section>
+
+
+</body>
+</document>
diff --git a/build-legacy/core/xdocs/userGuide/configuration.xml