http://git-wip-us.apache.org/repos/asf/struts-examples/blob/0677ec5c/mailreader/src/main/webapp/tour.html ---------------------------------------------------------------------- diff --git a/mailreader/src/main/webapp/tour.html b/mailreader/src/main/webapp/tour.html new file mode 100644 index 0000000..7dc29f0 --- /dev/null +++ b/mailreader/src/main/webapp/tour.html @@ -0,0 +1,2470 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> + +<html xmlns="http://www.w3.org/1999/xhtml";> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"/> + <link rel="stylesheet" type="text/css" href="../css/mailreader.css"/> + + <title>A Walking Tour of the Struts 2 MailReader Application</title> +</head> + +<body> +<blockquote> +<h2>A Walking Tour of the Struts 2 MailReader Application</h2> + +<p> + <i> + This article is meant to introduce a new user to Apache Struts 2 by + "walking through" a simple, but functional, application. + The article includes code snippets, but for the best result, you might + want to install the MailReader application on your own development + workstation and follow along. + Of course, the full source code to the MailReader is included in the + distribution. + </i> +</p> + +<p> + <i> + The tour assumes the reader has a basic understanding of the Java + language, JavaBeans, web applications, and JavaServer Pages. For + background on these technologies, see the + <a href="http://struts.apache.org/primer.html";> + Key Technologies Primer</a>. + </i> +</p> + +<hr/> + +<ul> + <li> + <a href="#Welcome">Welcome</a> + + <ul> + <li><a href="#web.xml">web.xml and resources.properties</a></li> + + <li><a href="#Welcome.do">Welcome.do</a></li> + + <li><a href="#Welcome.java">Welcome Action</a></li> + + <li><a href="#global-results">Global Results</a></li> + + <li><a href="#ApplicationListener.java">ApplicationListener.java</a></li> + + <li><a href="#resources.properties">Message Resources</a></li> + + <li><a href="#Welcome.jsp">Welcome Page</a></li> + + </ul> + </li> +</ul> + +<ul> + <li> + <a href="#Login">Login</a> + <ul> + + <li><a href="#Login.jsp">Login Page</a></li> + + <li><a href="#Login-validation.xml">Login-validation.xml</a></li> + + <li><a href="#Login.java">Login.java</a></li> + + <li><a href="#MailreaderSupport.java">MailreaderSupport.java</a></li> + + <li><a href="#Login.xml">Login Configuration</a></li> + + </ul> + </li> +</ul> + +<ul> + <li> + <a href="#MainMenu">MainMenu</a> + </li> +</ul> + +<ul> + <li> + <a href="#Registration.jsp">Registration page</a> + <ul> + <li><a href="#iterator">iterator</a></li> + </ul> + </li> +</ul> + +<ul> + <li> + <a href="#Subscription">Subscription</a> + + <ul> + <li><a href="#Subscription.java">Subscription.java</a> + </li> + </ul> + </li> +</ul> +<hr/> + +<p> + The premise of the MailReader is that it is the first iteration of a + portal application. + This version allows users to register and maintain a set of + accounts with various mail servers. + If completed, the application would let users read mail from their + accounts. +</p> + +<p> + The MailReader application demonstrates registering with an application, + logging into an application, maintaining a master record, and maintaining + child records. + This article overviews the constructs needed to do these things, + including the server pages, Java classes, and configuration elements. +</p> + +<p> + For more about the MailReader, including alternate implementations and a + set of formal Use Cases, + please visit the <a href="http://www.StrutsUniversity.org/MailReader";> + Struts University MailReader site</a>. +</p> + +<hr/> +<blockquote> + <p><font class="hint"> + <strong>JAAS</strong> - + Note that for compatibility and ease of deployment, the MailReader + uses "application-based" authorization. + However, use of the standard Java Authentication and Authorization + Service (JAAS) is recommended for most applications. + (See the <a + href="http://struts.apache.org/primer.html";> + Key Technologies Primer</a> for more about + authentication technologies.) + </font></p> +</blockquote> +<hr/> + +<p> + The tour starts with how the initial welcome page is displayed, and + then steps through logging into the application and editing a subscription. + Please note that this not a quick peek at a "Hello World" application. + The tour is a rich trek into a realistic, best practices application. + You may need to adjust your chair and get a fresh cup of coffee. + Printed, the article is 29 pages long (US). +</p> + +<h3><a name="Welcome" id="Welcome">Welcome Page</a></h3> + +<p> + A web application, like any other web site, can specify a list of welcome pages. + When you open a web application without specifying a particular page, a + default "welcome page" is served as the response. +</p> + +<h4><a name="web.xml" id="web.xml">web.xml</a></h4> + +<p> + When a web application loads, + the container reads and parses the "Web Application Deployment + Descriptor", or "web.xml" file. + The framework plugs into a web application via a servlet filter. + Like any filter, the "struts2" filter is deployed via the "web.xml". +</p> + +<hr/> +<h5>web.xml - The Web Application Deployment Descriptor</h5> +<pre><code><?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 2 MailReader</display-name> + + <strong><filter> + <filter-name>struts2</filter-name> + <filter-class> + org.apache.struts2.dispatcher.FilterDispatcher + </filter-class> + </filter></strong> + + <filter-mapping> + <filter-name><strong>struts2</strong></filter-name> + <url-pattern>/*</url-pattern> + </filter-mapping> + + <listener> + <listener-class> + org.springframework.web.context.ContextLoaderListener + </listener-class> + </listener> + + <!-- Application Listener for MailReader database --> + <listener> + <listener-class> + mailreader2.ApplicationListener + </listener-class> + </listener> + + <welcome-file-list> + <welcome-file>index.html</welcome-file> + </welcome-file-list> + + </web-app></code></pre> +<hr/> + +<p> + You might note that the web.xml configuration does not specify which file extension + to use with actions. + The default extension for Struts 2 is ".action", + but the extension can be changed in the struts.properties file. + For compatability with prior releases, the MailReader uses a .do extension for actions. +</p> + +<hr/> +<h5>struts.properties</h5> +<pre><code>struts.action.extension = <strong>do</strong></code></pre> +<hr/> + +<p> + The web.xml does specify a "Welcome File List" for the application. + When a web address refers to a directory rather than an individual file, + the container consults the Welcome File List for the name of a page to + open by default. +</p> + +<p> + However, most Struts applications do not refer to physical pages, + but to "virtual resources" called <i>actions</i>. + Actions specify code that we want to be run before a page + or other resource renders the response. + An accepted practice is to never link directly to server pages, + but only to logical action mappings. + By linking to actions, developers can often "rewire" an application + without editing the server pages. +</p> + +<hr/> +<h5>Best Practice:</h5> +<blockquote> + <p><font class="hint">"Link actions not pages."</font></p> +</blockquote> +<hr/> + +<p> + The actions are listed in one or more XML configuration files, + the default configuration file being named "struts.xml". + When the application loads, the struts.xml, and any other files + it includes, are parsed, and the framework creates a set of + configuration objects. + Among other things, the configuration maps a request for a certain + page to a certain action mapping. +</p> + + +<p> + Sites can list zero or more "Welcome" pages in the web.xml. + <a href="http://forum.java.sun.com/thread.jspa?threadID=721445";> + Unless you are using Java 1.5,</a> + actions cannot be specified as a Welcome page. + So, in the case of a Welcome page, + how do we follow the best practice of navigating through actions + rather than pages? +</p> + +<p> + One solution is to use a page to "bootstrap" one of our actions. + We can register the usual "index.html" as the Welcome page and have it + redirect to a "Welcome" action. +</p> + +<hr/> +<h5>MailReader's index.html</h5> +<pre><code><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> +<html><head> + <META HTTP-EQUIV="Refresh" CONTENT="0;<strong>URL=Welcome.do</strong>"> + </head> + <body> + <p>Loading ...</p> +</body></html></code></pre> +<hr/> + +<p> + As an alternative, + we could also have used a JSP page that issued the redirect with a Struts tag, + but a plain HTML solution works as well. +</p> + +<h4><a name="Welcome.do" id="Welcome.do">Welcome.do</a></h4> + +<p> + When the client requests "Welcome.do", the request is passed to the "struts2" + FilterDispatcher (that we registered in the web.xml file). + The FilterDispatcher retrieves the appropriate action mapping from the + configuration. + If we just wanted to forward to the Welcome page, we could use a simple + configuration element. +</p> +<hr/> +<h5>A simple "forward thru" action element</h5> +<pre><code><action name="<strong>Welcome</strong>"> + <result><strong>/pages/Welcome.jsp</strong></result> +</action></code></pre> +<hr/> + +<p> + If a client asks for the Welcome action ("Welcome.do"), the "/page/Welcome.jsp" + page would be returned in response. + The client does not know, or need to know, that the physical resource is located at + "/pages/Welcome.jsp". + All the client knows is that it requested the resource "Welcome.do". +</p> + +<p> + But if we peek at the configuration file for the MailReader, + we find a slightly more complicated XML element for the Welcome action. +</p> + +<hr/> +<h5>The Welcome action element</h5> +<pre><code><action name="Welcome" <b>class="mailreader2.Welcome"</b>> + <result>/pages/Welcome.jsp</result> + <strong><interceptor-ref name="guest"/></strong> + </action></code></pre> +<hr/> + +<p> + Here, the <strong>Welcome</strong> Java class executes whenever + someone asks for the Welcome action. + As it completes, the Action class can select which "result" is displayed. + The default result name is "success". + Another available result, defined at a global scope, is "error". +</p> + +<hr/> +<h5>Key concept:</h5> +<blockquote> + <p> + The Action class doesn't need to know what result type is needed + for "success" or "error". + The Action can just return the logical name for a result, + without knowing how the result is implemented. + </p> +</blockquote> +<hr/> + +<p> + The net effect is that all of the result details, + including the paths to server pages, + all can be declared <em>once</em> in the configuration. + Tightly coupled implementation details are not scattered all over + the application. +</p> + +<hr/> +<h5>Key concept:</h5> +<blockquote> + <p> + The Struts configuration lets us separate concerns and "say it once". + The configuration helps us "normalize" an application, + in much the same way we normalize a database schema. + </p> +</blockquote> +<hr/> + + +<p> + OK ... but why would a Welcome Action want to choose between "success" and + "error"? +</p> + +<h4><a name="Welcome.java" id="Welcome.java">Welcome Action</a></h4> + +<p> + The MailReader application retains a list of users along with their email + accounts. + The application stores this information in a database. + If the application can't connect to the database, the application can't do + its job. + So before displaying the Welcome <strong>page</strong>, the Welcome + <strong>class</strong> checks to see if the database is available. +</p> + +<p> + The MailReader is also an internationalized application. + So, the Welcome Action class checks to see if the message resources are + available too. + If both resources are available, the class passes back the "success" token. + Otherwise, the class passes back the "error" token, + so that the appropriate messages can be displayed. +</p> + +<hr/> +<h5>The Welcome Action class</h5> +<pre><code>package mailreader2; +public class Welcome extends MailreaderSupport { + + public String execute() { + + // Confirm message resources loaded + String message = getText(Constants.ERROR_DATABASE_MISSING); + if (Constants.ERROR_DATABASE_MISSING.equals(message)) { + <strong>addActionError(Constants.ERROR_MESSAGES_NOT_LOADED);</strong> + } + + // Confirm database loaded + if (null==getDatabase()) { + <strong>addActionError(Constants.ERROR_DATABASE_NOT_LOADED);</strong> + } + + if (hasErrors()) { + <strong>return ERROR;</strong> + } + else { + <strong>return SUCCESS;</strong> + } + } +}</code></pre> +<hr/> + +<p> + Several common result names are predefined, + including ERROR, SUCCESS, LOGIN, NONE, and INPUT, + so that these tokens can be used consistently across Struts 2 applications. +</p> + + +<h4><a name="global-results" id="global-results">Global Results</a></h4> + +<p> + As mentioned, "error" is defined in a global scope. + Other actions may have trouble connecting to the database later, + or other unexpected errors may occur. + The MailReader defines the "error" result as a Global Result, + so that any action can use it. +</p> + +<hr/> +<h5>MailReader's global-result element</h5> +<pre><code> <global-results> + <result name=<strong>"error"</strong>><strong>/pages/Error.jsp</strong></result> + <result name="invalid.token">/pages/Error.jsp</result> + <result name="login" type="redirect-action">Login_input</result> +</global-results></code></pre> +<hr/> + +<p> + Of course, if an individual action mapping defines its own "error" result type, + the local result would be used instead. +</p> + +<h4><a name="ApplicationListener.java" id="ApplicationListener.java">ApplicationListener.java</a> +</h4> + +<p> + The database is exposed as an object stored in application scope. + The database object is based on an interface. + Different implementations of the database could be loaded without changing + the rest of the application. + But how is the database object loaded in the first place? +</p> + +<p> + The database is created by a custom Listener that we configured in the "web.xml". +</p> + +<hr/> +<h5>mailreader2.ApplicationListener</h5> +<pre><code> <listener> + <listener-class> + <strong>mailreader2.ApplicationListener</strong> + </listener-class> +</listener></code></pre> +<hr/> + +<p> + By default, our ApplicationListener loads a <strong>MemoryDatabase</strong> + implementation of the UserDatabase. + MemoryDatabase stores the database content as a XML document, + which is parsed and loaded as a set of nested hashtables. + The outer table is the list of user objects, each of which has its own + inner hashtable of subscriptions. + When you register, a user object is stored in this hashtable. + When you login, the user object is stored within the session context. +</p> + +<p> + The database comes seeded with a sample user. + If you check the "database.xml" file under "/src/main/resources", + you'll see the sample user described in XML. +</p> + +<hr/> +<h5>The "seed" user element from the MailReader database.xml</h5> +<pre><code><user username="<strong>user</strong>" fromAddress="john.u...@somewhere.com" + fullName="<strong>John Q. User</strong>" password="<strong>pass</strong>"> + <subscription host="<strong>mail.hotmail.com"</strong> autoConnect="false" + password="bar" type="pop3" username="user1234"> + </subscription> + <subscription host="<strong>mail.yahoo.com</strong>" autoConnect="false" password="foo" + type="imap" username="jquser"> + </subscription> +</user></code></pre> +<hr/> + +<p> + The "seed" user element creates a registration record for "John Q. User", + with the subscription detail for his hotmail and yahoo accounts. +</p> + +<h4><a name="resources.properties" id="resources.properties">Message Resources</a> +</h4> + +<p> + As mentioned, MailReader is an internationalized application. + In Struts 2, message resources are associated with the Action class being processed. + If we check the source, we find a language resource bundle named + <em>MailreaderSupport.</em> + MailreaderSupport is our base class for all the MailReader Actions. + Since all of our Actions extend MailreaderSupport, + all of our Actions can use the same resource bundle. +</p> + +<hr/> +<h5>Message Resource entries used by the Welcome page</h5> +<pre><code><strong>index.heading=</strong>MailReader Application Options +<strong>index.login=</strong>Log on to the MailReader Application +<strong>index.registration=</strong>Register with the MailReader Application +<strong>index.title=</strong>MailReader Demonstration Application +<strong>index.tour=</strong>A Walking Tour of the MailReader Demonstration Application</code></pre> +<hr/> + +<p> + If you change a message in the resource, and then rebuild and reload the + application, the change will appear throughout the application. + If you provide message resources for additional locales, you can + localize your application. + The MailReader provides resources for English, Russian, and Japanese. +</p> + +<h4><a name="Welcome.jsp" id="Welcome.jsp">Welcome Page</a></h4> + +<p> + After confirming that the necessary resources exist, the Welcome action + forwards to the Welcome page. +</p> +<hr/> +<h5>Welcome.jsp</h5> +<pre><code><%@ page contentType="text/html; charset=UTF-8" %> +<strong><%@ taglib prefix="s" uri="http://struts.apache.org/tags"; %></strong> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> + <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> + <head> + <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> + <title><strong><s:text name="index.title"/></strong></title> + <link href="<strong><s:url value="/css/mailreader.css"/></strong>" rel="stylesheet" + type="text/css"/> + </head> + + <body> + <h3><s:text name="index.heading"/></h3> + + <ul> + <li><a href="<s:url action="Registration_input"/>"><s:text + name="index.registration"/></a></li> + <li><a href="<s:url action="Login_input"/>"><s:text + name="index.login"/></a></li> + </ul> + + <h3>Language Options</h3> + <ul> + <li> + <s:url id="en" action="Welcome"> + <s:param name="request_locale">en</s:param> + </s:url> + <s:a href="%{en}">English</s:a> + </li> + <li> + <s:url id="ja" action="Welcome"> + <s:param name="request_locale">ja</s:param> + </s:url> + <s:a href="%{ja}">Japanese</s:a> + </li> + <li> + <s:url id="ru" action="Welcome"> + <s:param name="request_locale">ru</s:param> + </s:url> + <s:a href="%{ru}">Russian</s:a> + </li> + </ul> + + <hr /> + + <p><strong><s:i18n name="alternate"></strong> + <img src="<s:text name="struts.logo.path"/>" + alt="<s:text name="struts.logo.alt"/>"/> + <strong></s:i18n></strong></p> + + <p><a href="<s:url action="Tour" />"><s:text name="index.tour"/></a></p> + + </body> +</html></code></pre> +<hr/> + +<p> + At the top of the Welcome page, there are several directives that load the + Struts 2 tag libraries. + These are just the usual red tape that goes with any JSP file. + The rest of the page utilizes three Struts JSP tags: + "text", "url", and "i18n". +</p> + +<p> + (We use the tag prefix "s:" in the Struts 2 MailReader application, + but you can use whatever prefix you like in your applications.) +</p> + +<p> + The <strong>text</strong> tag inserts a message from an + application's default resource bundle. + If the framework's locale setting is changed for a user, + the text tag will render messages from the new locale's resource + bundle instead. +</p> + +<p> + The <strong>url</strong> tag can render a reference to an + action or any other web resource, + applying "URL encoding" to the hyperlinks as needed. + Java's URL encoding feature lets your application maintain client state + without requiring cookies. +</p> + +<hr/> +<h5>Tip:</h5> +<blockquote> + <p><font class="hint"> + <strong>Cookies</strong> - + If you turn cookies off in your browser, and then reload your browser + and this page, + you will see the links with the Java session id information attached. + (If you are using Internet Explorer and try this, + be sure you reset cookies for the appropriate security zone, + and that you disallow "per-session" cookies.) + </font></p> +</blockquote> +<hr/> + +<p> + The <strong>i18n</strong> tag provides access to multiple resource bundles. + The MailReader application uses a second set of message resources for + non-text elements. + When these are needed, we use the "i18n" tag to specify a different bundle. +</p> + +<p> + The <strong>alternate</strong> bundle is stored in the {{/src/main/resources}} folder, + so that it ends up under "classes", which is on the application's class path. +</p> + +<p> + In the span of a single request for the Welcome page, the framework has done + quite a bit already: +</p> + +<ul> + <li> + Confirmed that required resources were loaded during initialization. + </li> + + <li> + Written all the page headings and labels from internationalized + message resources. + </li> + + <li> + Automatically URL-encoded paths as needed. + </li> +</ul> + +<p> + When rendered, the Welcome page lists two menu options: + one to register with the application and one to log on (if you have + already registered). + Let's follow the Login link first. +</p> + +<h3><a name="Login" id="Login">Login</a></h3> + +<p> + If you choose the Login link, and all goes well, the Login action forwards + control to the Login page. +</p> + +<h4><a name="Login.jsp" id="Login.jsp">Login Page</a></h4> + +<p> + The Login page displays a form that accepts a username and password. + You can use the default username and password to login + (<strong>user</strong> and <strong>pass</strong>), if + you like. Try omitting or misspelling the username and password in + various combinations to see how the application reacts. + Note that both the username and password are case sensitive. +</p> + +<hr/> +<h5>Login.jsp</h5> +<pre><code><%@ page contentType="text/html; charset=UTF-8" %> + <%@ taglib prefix="s" uri="http://struts.apache.org/tags"; %> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> + <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> + <head> + <title><s:text name="login.title"/></title> + <link href="<s:url value="/css/mailreader.css"/>" rel="stylesheet" + type="text/css"/> + </head> + <body onLoad="self.focus();document.Login.username.focus()"> + <strong><s:actionerror/></strong> + <strong><s:form action="Login" validate="true"></strong> + <strong><s:textfield key="username"/></strong> + <strong><s:password key="password"/></strong> + <strong><s:submit key="button.save"/></strong> + <strong><s:reset key="button.reset"/></strong> + <s:submit <strong>action="Login_cancel" onclick="form.onsubmit=null"</strong> + key="button.cancel"/> + </s:form> + <jsp:include page="Footer.jsp"/> + </body> +</html></code></pre> +<hr/> + +<p> + We already saw some of the tags used by the Login page on the Welcome page. + Let's focus on the new tags. +</p> + +<p> + The first new tag on the Login page is <strong>actionerrors</strong>. + Most of the possible validation errors are related to a single field. + If you don't enter a username, + the framework can place an error message near the tag prompting you to + enter a username. + But some messages are not related to a single field. + For example, the database might be down. + If the action returns an "Action Error", as opposed to a "Field Error", + the messages are rendered in place of the "actionerror" tag. + The text for the validation errors, whether they are Action Errors or + Field Errors, can be specified in the resource bundle, + making the messages easy to manage and localize. +</p> + +<p> + The second new tag is <strong>form</strong>. + This tag renders a HTML form tag. + The "validate=true" setting enables client-side validation, + so that the form can be validated with JavaScript before being sent + back to the server. + The framework will still validate the form again, just to be sure, but the + client-side validation can save a few round-trips to the server. +</p> + +<p> + Within the form tag, + we see four more new tags: "textfield", "password", "submit", + and "reset". We also see a second usage of "submit" that utilizes an + "action" attribute. +</p> + +<p> + When we place a control on a form, we usually need to code a set of + HTML tags to do everything we want to do. + Most often, we do not just want a plain "input type=text" tag. + We want the input field to have a label too, and maybe even + a tooltip. And, of course, a place to print a message + should invalid data be entered. +</p> + +<p> + The Struts Tags support templates and themes so that a set of HTML tags can be + rendered from a single Struts Tag. For example, the single tag +</p> + +<pre><code> + <s:<strong>textfield</strong> key="username"/> +</code></pre> + +<p> + generates a wad of HTML markup. +</p> + +<hr/> +<pre><code><tr> + <td class="tdLabel"> + <label for="Login_username" class="label">Username:</label> + </td> + <td> + <input type="text" name="username" value="" id="Login_username"/> + </td> +</tr></code></pre> +<hr/> + +<p> + If for some reason you don't like the markup generated by a Struts Tag, + it's each to change. + Each tag is driven by a template that can be updated on a tag-by-tag basis. + For example, + here is the default template that generates the markup for the ActionErrors tag: +</p> + +<hr/> +<pre><code><#if (actionErrors?exists && actionErrors?size > 0)> + <ul> + <#list actionErrors as error> + <li><span class="errorMessage">${error}</span></li> + </#list> + </ul> +</#if></code></pre> +<hr/> + +<p> + If you wanted ActionErrors displayed in a table instead of a list, + you could edit a copy of this file, save it as a file named + "template/simple/actionerror.ftl", + and place this one file at the base of your application's classpath. +</p> + +<hr/> +<pre><code><#if (actionErrors?exists && actionErrors?size > 0)> + <strong><table></strong> + <#list actionErrors as error> + <strong><tr><td></strong><span class="errorMessage">${error}</span><strong></td></tr></strong> + </#list> + <strong></table></strong> +</#if></code></pre> +<hr/> + +<p> + Under the covers, the framework uses + <a href="http://freemarker.sourceforge.net/";>Freemarker</a> + for its standard templating language. + FreeMarker is similar to + <a href="http://jakarta.apache.org/velocity/";>Velocity</a>, + but it offers better error reporting and some additional features. + If you prefer, Velocity and JSP templates can also be used to create your own tags. +</p> + +<p> + The <strong>password</strong> tag renders a "input type=password" + tag, along with the usual template/theme markup. + By default, the password tag will not retain input if the submit fails. + If the username is wrong, + the client will have to enter the password again too. + (If you did want to retain the password when validation fails, + you can set the tag's "showPassword" property to true.) +</p> + +<p> + Unsurprisingly, the <strong>submit</strong> and <strong>reset</strong> tags + render buttons of the corresponding types. +</p> + +<p> + The second submit button is more interesting. +</p> + +<pre><code> <s:submit <strong>action="Login_cancel" onclick="form.onsubmit=null"</strong> + key="button.cancel"/> +</code></pre> + +<p> + Here we are creating the Cancel button for the form. + The button's attribute <em>action="Login<strong>_</strong>cancel"</em> + tells the framework to submit to the Login's "cancel" method + instead of the usual "execute" method. + The <em>onclick="form.onsubmit=null"</em> script defeats client-side validation. + On the server side, "cancel" is on a special list of methods that bypass validation, + so the request will go directly to the Action's <strong>cancel</strong> method. + Another entry on the special-case list is the "input" method. +</p> + +<hr/> +<h5>Tip:</h5> +<blockquote> + <p><font class="hint"> + The Struts Tags have options and capabilities beyond what we have shown here. + For more see, the <a href="http://cwiki.apache.org/WW/tag-developers-guide.html";> + Struts Tag documentation.</a> + </font></p> +</blockquote> +<hr/> + +<p> + OK, but how do the tags know that both of these fields are required? + How do they know what message to display when the fields are empty? +</p> + +<p> + For the answers, we need to look at another flavor of configuration file: + the "validation" file. +</p> + +<h4><a name="Login-validation.xml" id="Login-validation.xml">Login-validation.xml</a> +</h4> + +<p> + While it is not hard to code data-entry validation into an Action class, + the framework provides an even easier way to validate input. +</p> + +<p> + The validation framework is configured through another XML document, the <strong> + Login-validation.xml</strong>. +</p> + +<hr/> +<h5>Validation file for Login Action</h5> +<pre><code><!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" + "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd";> +<validators> + <field name="<strong>username</strong>"> + <field-validator type="<strong>requiredstring</strong>"> + <message key="<strong>error.username.required</strong>"/> + </field-validator> + </field> + <field name="<strong>password</strong>"> + <field-validator type="<strong>requiredstring</strong>"> + <message key="<strong>error.password.required</strong>"/> + </field-validator> + </field> +</validators> +</code></pre> +<hr/> + +<p> + You may note that the DTD refers to "XWork". + <a href="http://www.opensymphony.com/xwork/";> + Open Symphony XWork + </a> is a generic command-pattern framework that can be used outside of a + web environment. Essentially, Struts 2 is a web-based extension of the + XWork framework. +</p> + +<p> + The field elements correspond to the ActionForm properties. + The <strong>username</strong> and <strong>password</strong> field elements + say that each field depends on the "requiredstring" validator. + If the username is blank or absent, validation will fail and an error + message is generated. + The messages would be based on the "error.username.required" or + "error.password.required" message templates from the resource bundle. +</p> + +<!-- +<p> + The <strong>password</strong> field (or property) is also required. + In addition, it must also pass the "maxlength" and "minlength" + validations. + Here, the minimum length is three characters and the maximum length is + sixteen. + If the length of the password doesn't meet these criteria, a corresponding + error message is generated. + Of course, the messages are generated from the MessageResource bundles and + are easy to localize. +</p> +--> + +<h4><a name="Login.java" id="Login.java">Login Action</a></h4> + +<p> + If validation passes, the framework invokes the "execute" method of the Login Action. + The actual Login Action is brief, since most of the functionality derives + from the base class, <strong>MailreaderSupport</strong>. +</p> + +<hr/> +<h5>Login.java</h5> +<pre><code>package mailreader2; +import org.apache.struts.apps.mailreader.dao.User; +public final class <strong>Login</strong> extends MailreaderSupport { +public String <strong>execute()</strong> throws ExpiredPasswordException { + User user = <strong>findUser(getUsername(), getPassword());</strong> + if (user != null) { + <strong>setUser(user);</strong> + } + if (<strong>hasErrors()</strong>) { + return INPUT; + } + return SUCCESS; + } +}</code></pre> +<hr/> + +<p> + Login lays out what we do to authenticate a user. + We try to find the user using the credentials provided. + If the user is found, we cache a reference. + If the user is not found, we return "input" so the client can try again. + Otherwise, we return "success", so that the client can access the rest of the application. +</p> + +<h4><a name="MailreaderSupport.java" id="MailreaderSupport.java">MailreaderSupport.java</a></h4> + +<p> + Let's look at the relevant properties and methods from MailreaderSupport + and another base class, <strong>ActionSupport</strong>, namely + "getUsername", "getPassword", "findUser", "setUser", and "hasErrors". +</p> + +<p> + The framework lets you define + <a href="http://struts.apache.org/primer.html#javabeans";>JavaBean properties</a> + directly on the Action. + Any JavaBean property can be used, including rich objects. + When a request comes in, + any public properties on the Action class are matched with the request parameters. + When the names match, the request parameter value is set to the JavaBean property. + The framework will make its best effort to convert the data, + and, if necessary, it will report any conversion errors. +</p> + +<p> + The <strong>Username</strong> and <strong>Password</strong> properties are nothing fancy, + just standard JavaBean properties. +</p> + +<hr/> +<h5>MailreaderSupport.getUsername() and getPassword()</h5> +<pre><code>private String username = null; +public String <strong>getUsername()</strong> { + return this.username; +} +public void setUsername(String username) { + this.username = username; +} + +private String password = null; +public String <strong>getPassword()</strong> { + return this.password; +} +public void setPassword(String password) { + this.password = password; +}</code></pre> +<hr/> + +<p> + We use these properties to capture the client's credentials, + and pass them to the more interesting <strong>findUser</strong> method. +</p> + +<hr/> +<h5>MailreaderSupport.findUser</h5> +<pre><code>public User <strong>findUser</strong>(String username, String password) + throws <strong>ExpiredPasswordException</strong> { + User user = <strong>getDatabase().findUser(username)</strong>; + if ((user != null) && !user.getPassword().equals(password)) { + user = null; + } + if (user == null) { + this.<strong>addFieldError</strong>("password", getText("error.password.mismatch")); + } + return user; +}</code></pre> +<hr/> + +<p> + The "findUser" method dips into the MailReader Data Access Object layer, + which is represented by the <strong>Database</strong> property. + The code for the DAO layer is maintained as a separate component. + The MailReader application imports the DAO JAR, + but it is not responsible for maintaining any of the DAO source. + Keeping the data access layer at "arms-length" is a very good habit. + It encourages a style of development where the data access layer + can be tested and developed independently of a specific end-user application. + In fact, there are several renditions of the MailReader application, + all which share the same MailReader DAO JAR! +</p> + +<hr/> +<h5>Best Practice:</h5> +<blockquote> + <p> + <font class="hint">"Strongly separate data access and business logic from the rest of + the application."</font> + </p> +</blockquote> +<hr/> + +<p> + When "findUser" returns, + the Login Action looks to see if a valid (non-null) User object is returned. + A valid User is passed to the <strong>User property</strong>. + Although it is still a JavaBean property, + the User property is not implemented in quite the same way as Username and Password. +</p> + +<hr/> +<h5>MailreaderSupport.setUser</h5> +<pre><code>public User getUser() { + return (User) <strong>getSession().get(Constants.USER_KEY)</strong>; +} +public void setUser(User user) { + getSession().put(Constants.USER_KEY, user); +}</code></pre> +<hr/> + +<p> + Instead of using a field to store the property value, + "setUser" passes it to a <strong>Session</strong> property. +</p> + +<hr /> +<h5>MailreaderSupport.getSession() and setSession()</h5> +<pre><code>private Map session; +public Map <strong>getSession()</strong> { + return session; + +public void <strong>setSession(Map value)</strong> { + session = value; +}</code></pre> +<hr /> + +<p> + To look at the MailreaderSupport class, + you would think the Session property is a plain-old Map. + In fact, + the Session property is an adapter that is backed by the servlet session object at runtime. + The MailreaderSupport class doesn't need to know that though. + It can treat Session like any other Map. + We can also test the MailreaderSupport class by passing it some other implementation of + Map, running the test, + and then looking to see what changes MailreaderSupport made to our "mock" Session object. +</p> + +<p> + But, when MailreaderSupport is running inside a web application, + how does it acquire a reference to the servlet session? +</p> + +<p> + Good question. If you were to look at just the MailreaderSupport class, + you would not see a single line of code that sets the session property. + But, yet, when we run the class, the session property is not null. + Hmmm. +</p> + +<p> + The magic that provides the Session property a runtime value is called + "dependency injection". + The MailreaderSupport class implements a interface called <strong>SessionAware</strong>. + SessionAware is bundled with the framework, + and it defines a setter for the Session property. +</p> + +<p> + <code>public void <strong>setSession</strong>(Map session);</code> +</p> + +<p> + Also bundled with the framework is an object called the + <strong>ServletConfigInterceptor</strong>. + If the ServletConfigInterceptor sees that an Action implements the SessionAware interface, + it automatically set the session property. +</p> + +<pre><code>if (action instanceof <code>SessionAware</code>) { + ((SessionAware) action).<code>setSession</code>(context.getSession()); +}</code></pre> + +<p> + The framework uses these "Interceptor" classes to create a <strong>front controller</strong> + for each action an application defines. + Each Interceptor can peek at the request before an Action class is invoked, + and then again after the Action class is invoked. + (If you have worked with Servlet + <a href="http://struts.apache.org/primer.html#filters";>Filters</a>, + you will recognize this pattern. + But, unlike Filters, Interceptors are not tied to HTTP. + Interceptors can be tested and developed outside of a web application.) +</p> + +<p> + You can use the same set of Interceptors for all your actions, + or define a special set of Interceptors for any given action, + or define different sets of Interceptors to use with different types of actions. + The framework comes with a default set of Interceptors, + that it will use when another set is not specified, + but you can designate your own default Interceptor set (or "stack") + in the Struts configuration. +</p> + +<p> + Many Interceptors provide a utility or helper functions, + like setting the session property. + Others, like the <strong>ValidationInterceptor</strong>, + can change the workflow of an action. + Interceptors are key feature of the framework, + and we will see a few more on the tour. +</p> + +<p> + If a valid User is not found, or the password doesn't match, + the "findUser" method invokes the <strong>addFieldError</strong> method to note the + problem. + When "findUser" returns, the Login Action checks for errors, + and then it returns either INPUT or SUCCESS. +</p> + +<p> + The "addFieldError" method is provided by the ActionSupport class, + which is bundled with the framework. + The constants for INPUT and SUCCESS are also provided by ActionSupport. + While the ActionSupport class provides many useful utilities, + you are not required to use it as a base class. + Any Java class can be used as an Action, if you like. +</p> + +<p> + It is a good practice to provide a base class with utilities + that can be shared by an application's Action classes. + The framework does this with ActionSupport, + and the MailReader application does the same with the MailreaderSupport class. +</p> + +<hr/> +<h5>Best Practice:</h5> +<blockquote> + <p><font class="hint">"Use a base class to define common functionality."</font></p> +</blockquote> +<hr/> + +<p> + But, what happens if Login returns INPUT instead of SUCCESS. + How does the framework know what to do next? +</p> + +<p> + To answer that question, + we need to turn back to the Struts configuration + and look at how Login is declared. +</p> + + +<h4><a name="Login.xml" id="Login.xml">Login Configuration</a></h4> + +<p> + The Login action element outlines how the Login workflow operates, + including what to do when the Action returns "input", + or the default result name "success". +</p> + +<hr/> +<h5>mailreader-support.xml Login</h5> +<pre><code><action name="<strong>Login_*</strong>" method="{1}" class="mailreader2.Login"> + <result name="<strong>input</strong>">/pages/Login.jsp</result> + <result name="<strong>cancel</strong>" type="redirect-action">Welcome</result> + <result type="redirect-action">MainMenu</result> + <result name="<strong>expired</strong>" type="chain">ChangePassword</result> + <<strong>exception-mapping</strong> + exception="org.apache.struts.apps.mailreader.dao.ExpiredPasswordException" + result="<strong>expired</strong>"/> + <interceptor-ref name="<strong>guest</strong>"/> +</action></code></pre> +<hr/> + +<p> + You might notice that the name of the Login action element is not "Login" + but "Login<strong>_*</strong>". + The asterisk is a special "wildcard" notation that tells the framework to match any series + of character at this point. + In the method attribute, + the "{1}" notation indicates that framework should substitute whatever characters match + the asterisk at runtime. + When we cite actions like "Login_cancel" or "Login_input", + the framework matches "cancel" or "input" with the wildcard and fills in the blanks. +</p> + +<p> + The "trailing bang" notation was hardwired into WebWork 2. + To provide backward compatibility, + the notation is supported by Struts 2.0. + If you prefer to use wildcards to emulate the same notation, + as the Mailreader does, + you should disable the old notation in the Struts properties file. +</p> + +<hr/> +<h5>struts.properties</h5> +<pre><code>struts.enable.DynamicMethodInvocation = false</code></pre> +<hr/> + +<p> + Using wildcards with a exclamation point (or "bang") is not the only way we can use + wilcards to invoke methods. + If we wanted to use actions like "inputLogin", + we could move the asterisk and use an action name like "*Login". +</p> + +<p> + Within the Login action element, the first result element is named "input". + If validation or authentification fail, + the Action class will return "input" and the framework will transfer control to the + "Login.jsp" page. +</p> + +<p> + The second result element is named <strong>cancel</strong>. + If someone presses the cancel button on the Login page, + the Action class will return "cancel", this result will be selected, + and the framework will issue a redirect to the Welcome action. +</p> + +<p> + The third result has no name, + so it will be called if the default <strong>success</strong> token is returned. + So, if the Login succeeds, + control will transfer to the MainMenu action. +</p> + +<p> + The MailReader DAO exposes a "ExpiredPasswordException". + If the DAO throws this exception when the User logs in, + the framework will process the exception-mapping + and transfer control to the "ChangePassword" action. +</p> + +<p> + Just in case any other Exceptions are thrown, + the MailReader application also defines a global handler. +</p> + +<hr/> +<h5>mailreader-default.xml exception-mapping</h5> +<pre><code><global-exception-mappings> + <exception-mapping + result="error" + exception="java.lang.Exception"/> +</global-exception-mappings></code></pre> +<hr/> + +<p> + If an unexpected Exception is thrown, + the exception-mapping will transfer control to the action's "error" result, + or to a global "error" result. + The MailReader defines a global "error" result + which transfers control to an "Error.jsp" page + that can display the error message. +</p> + +<hr/> +<h5>Error.jsp</h5> +<pre><code><%@ page contentType="text/html; charset=UTF-8" %> +<%@ taglib prefix="s" uri="http://struts.apache.org/tags"; %> + <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> + <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> + <head> + <title>Unexpected Error</title> + </head> + <body> + <h2>An unexpected error has occured</h2> + <p> + Please report this error to your system administrator + or appropriate technical support personnel. + Thank you for your cooperation. + </p> + <hr /> + <h3>Error Message</h3> + <strong><s:actionerror /></strong> + <p> + <strong><s:property value="%{exception.message}"/></strong> + </p> + <hr /> + <h3>Technical Details</h3> + <p> + <strong><s:property value="%{exceptionStack}"/></strong> + </p> + <jsp:include page="Footer.jsp"/> + </body> +</html></code></pre> +<hr/> + +<p> + The Error page uses <strong>property</strong> tags to expose + the Exception message and the Exception stack. +</p> + +<p> + Finally, the Login action specifies an <strong>InterceptorStack</strong> + named <strong>defaultStack.</strong> + If you've worked with Struts 2 or WebWork 2 before, that might seem strange, + since "defaultStack" is the factory default. +</p> + +<p> + In the MailReader application, most of the actions are only available + to authenticated users. + The exceptions are the Welcome, Login, and Register actions + which are available to everyone. + To authenticate clients, + the MailReader uses a custom Interceptor and a custom Interceptor stack. +</p> + +<hr/> +<h5>mailreader2.AuthenticationInterceptor</h5> +<pre><code>package mailreader2; +import com.opensymphony.xwork2.interceptor.Interceptor; +import com.opensymphony.xwork2.ActionInvocation; +import com.opensymphony.xwork2.Action; +import java.util.Map; +import org.apache.struts.apps.mailreader.dao.User; + +public class <strong>AuthenticationInterceptor</strong> implements Interceptor { + public void destroy () {} + public void init() {} + public String <strong>intercept</strong>(ActionInvocation actionInvocation) throws Exception { + Map session = actionInvocation.getInvocationContext().getSession(); + User user = (User) session.get(Constants.USER_KEY); + boolean isAuthenticated = (null!=user) && (null!=user.getDatabase()); + if (<strong>isAuthenticated</strong>) { + return actionInvocation.invoke(); + } + else { + return Action.LOGIN; + } + } +}</code></pre> +<hr/> + +<p> + The <strong>AuthenticationInterceptor</strong> looks to see if a User object + has been stored in the client's session state. + If so, it returns normally, and the next Interceptor in the set would be invoked. + If the User object is missing, the Interceptors returns "login". + The framework would match "login" to the global result, + and transfer control to the Login action. +</p> + +<p> + The MailReader defines three custom Interceptor stacks: "user", "user-submit", + and "guest". +</p> + +<hr/> +<h5>mailreader-default.xml interceptors</h5> +<pre><code><interceptors> + <interceptor name="<strong>authentication</strong>" + class="mailreader2.AuthenticationInterceptor"/> + <interceptor-stack name="<strong>user</strong>" > + <interceptor-ref name="authentication" /> + <interceptor-ref name="defaultStack"/> + </interceptor-stack> + <interceptor-stack name="<strong>user-submit</strong>" > + <interceptor-ref name="tokenSession" /> + <interceptor-ref name="user"/> + </interceptor-stack> + <interceptor-stack name="<strong>guest</strong>" > + <interceptor-ref name="defaultStack"/> + </interceptor-stack> +</interceptors> +<<strong>default-interceptor-ref</strong> name="user"/></code></pre> +<hr/> + +<p> + The <strong>user</strong> stacks require that the client be authenticated. + In other words, that a User object is present in the session. + The actions using a <strong>guest</strong> stack can be accessed by any client. + The <strong>-submit</strong> versions of each can be used with actions + with forms, to guard against double submits. +</p> + +<h5>Double Submits</h5> + +<p> + A common problem with designing web applications is that users are impatient + and response times can vary. + Sometimes, people will press a submit button a second time. + When this happens, the browser submits the request again, + so that we now have two requests for the same thing. + In the case of registering a user, if someone does press the submit button + again, and their timing is bad, + it could result in the system reporting that the username has already been + used. + (The first time the button was pressed.) + In practice, this would probably never happen, but for a longer running + process, like checking out a shopping cart, + it's easier for a double submit to occur. +</p> + +<p> + To forestall double submits, and "back button" resubmits, + the framework can generate a token that is embedded in the form + and also kept in the session. + If the value of the tokens do not compare, + then we know that there has been a problem, + and that a form has been submitted twice or out of sequence. +</p> + +<p> + The Token Session Interceptor will also attempt to provide intelligent + fail-over in the event of multiple requests using the same session. + That is, it will block subsequent requests until the first request is complete, + and then instead of returning the "invalid.token" code, + it will attempt to display the same response that the + original, valid action invocation would have displayed +</p> + +<p> + Because the default interceptor stack will now authenticate the client, + we need to specify the standard "defaultStack" for the three + "guest actions", Welcome, Login, and Register. + Requiring authentification by default is the better practice, since it + means that we won't forget to enable it when creating new actions. + Meanwhile, those pesky users will ensure that we don't forget to disable + authentification for "guest" services. +</p> + +<h3><a name="MainMenu" id="MainMenu">MainMenu</a></h3> + +<p> + On a successful login, the Main Menu page displays. + If you logged in using the demo account, + the page title should be "Main Menu Options for John Q. User". + Below this legend should be two links: +</p> + +<ul> + <li> + Edit your user registration profile + </li> + <li> + Log off MailReader Demonstration Application + </li> +</ul> + +<p> + Let's review the source for the "MainMenu" action mapping, + and the "MainMenu.jsp". +</p> + +<hr/> +<h5>Action mapping element for MainMenu</h5> +<pre><code><action name="MainMenu" class="mailreader2.MailreaderSupport"> + <result>/pages/MainMenu.jsp</result> + </action></code></pre> + +<h5>MainMenu.jsp</h5> +<pre><code><%@ page contentType="text/html; charset=UTF-8" %> +<%@ taglib prefix="s" uri="http://struts.apache.org/tags"; %> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> + <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> + <head> + <title><s:text name="mainMenu.title"/></title> + <link href="<s:url value="/css/mailreader.css"/>" rel="stylesheet" + type="text/css"/> + </head> + + <body> + <h3><s:text name="mainMenu.heading"/> <strong><s:property + value="user.fullName"/></strong></h3> + <ul> + <li><a href="<s:url <strong>action="Registration_input"</strong> />"> + <s:text name="mainMenu.registration"/> + </a> + </li> + <li><a href="<s:url <strong>action="Logout"</strong> />"> + <s:text name="mainMenu.logout"/> + </a> + </ul> + </body> +</html></code></pre> +<hr/> + +<p> + The source for "MainMenu.jsp" also contains a new tag, <strong> + property</strong>, which we use to customize the page with the + "fullName" property of the authenticated user. +</p> + +<p> + Displaying the user's full name is the reason the MainMenu action + references the MailreaderSupport class. + The MailreaderSupport class has a User property that the text tag + can access. + If we did not utilize MailreaderSupport, + the property tag would not be able to find the User object to print + the full name. +</p> + +<p> + The customized MainMenu page offers two standard links. + One is to "Edit your user registration profile". + The other is to "Logout the MailReader Demonstration Application". +</p> + +<h3><a name="Registration.jsp" id="Registration.jsp">Registration page</a> +</h3> + +<p> + If you follow the "Edit your user registration profile" link from the Main + Menu page, + we will finally reach the heart of the MailReader application: the + Registration, or "Profile", page. + This page displays everything MailReader knows about you + (or at least your login), + while utilizing several interesting techniques. +</p> + +<p> + To do double duty as the "Create" Registration page and the "Edit" + Registration page, + the "Registration.jsp" makes extensive use of the test tags, + to make it appears as though there are two distinct pages. +</p> + +<hr /> +<h5>Registration.jsp - head element</h5> +<pre><code><head> + <s:if test="<strong>task=='Create'</strong>"> + <title><s:text name="registration.title.create"/></title> + </s:if> + <s:if test="<strong>task=='Edit'</strong>"> + <title><s:text name="registration.title.edit"/></title> + </s:if> + <link href="<s:url value="/css/mailreader.css"/>" rel="stylesheet" + type="text/css"/> +</head></code></pre> +<hr /> + +<p> + For example, if client is editing the form (task == 'Edit'), + the page inserts the username from the User object. + For a new Registration (task == 'Create'), + the page creates an empty data-entry field. +</p> + +<hr/> +<h5>Note:</h5> +<blockquote> + <p><font class="hint"> + <strong>Presention Logic</strong> - + The "test" tag is a convenient way to express presentation + logic within your pages. + Customized pages help to prevent user error, + and dynamic customization reduces the number of server pages your + application needs to maintain, among other benefits. + </font></p> +</blockquote> +<hr/> + +<p> + The page also uses logic tags to display a list of subscriptions + for the given user. + If the RegistrationForm has task set to "Edit", + the lower part of the page that lists the subscriptions is exposed. +</p> + +<hr/> +<h5></h5> +<pre><code><s:if test=<strong>"task == 'Edit'"</strong>> + <div align="center"> + <h3><s:text name="heading.subscriptions"/></h3> + </div> + <!-- ... --> + </s:if> +<jsp:include page="Footer.jsp"/> +</body></html></code></pre> +<hr/> + +<p> + Otherwise, the page contains just the top portion -- + a data-entry form for managing the user's registration. +</p> + +<h4><a name="iterator" id="iterator">iterator</a></h4> + +<p> + Besides "if" there are several other control tags that you can use + to sort, filter, or iterate over data. + The Registration page includes a good example of using the <strong>iterator</strong> + tag to display the User's Subscriptions. +</p> + +<p> + The subscriptions are stored in a hashtable object, which is in turn + stored in the user object. + So to display each subscription, we have to reach into the user object, + and loop through the members of the subscription collection. + Using the iterator tag, you can code it the way it sounds. + </p> + +<hr/> +<h5>Using iterator to list the Subscriptions</h5> +<pre><code><s:iterator value="<strong>user.subscriptions</strong>"> + <tr> + <td align="left"> + <s:property value="<strong>host</strong>"/> + </td> + <td align="left"> + <s:property value="<strong>username</strong>"/> + </td> + <td align="center"> + <s:property value="<strong>type</strong>"/> + </td> + <td align="center"> + <s:property value="<strong>autoConnect</strong>"/> + </td> + <td align="center"> + <a href="<s:url action="<strong>Subscription_delete</strong>"><s:param name="<strong>host</strong>" value="host"/></s:url>"> + <s:text name="registration.deleteSubscription"/> + </a> + <a href="<s:url action="<strong>Subscription_edit</strong>"><s:param name="<strong>host</strong>" value="host"/></s:url>"> + <s:text name="registration.editSubscription"/> + </a> + </td> + </tr> +</s:iterator></code></pre> +<hr/> + +<p> + When the iterator renders, it generates a list of Subscriptions for the current User. +</p> + +<hr /> + + <div align="center"> + <h3>Current Subscriptions</h3> + </div> + + <table border="1" width="100%"> + <tr> + <th align="center" width="30%"> + Host Name + </th> + <th align="center" width="25%"> + User Name + </th> + + <th align="center" width="10%"> + Server Type + </th> + <th align="center" width="10%"> + Auto + </th> + <th align="center" width="15%"> + Action + </th> + </tr> + <tr> + <td align="left"> + mail.hotmail.com + </td> + <td align="left"> + user1234 + </td> + <td align="center"> + pop3 + </td> + + <td align="center"> + false + </td> + <td align="center"> + <a href="/struts2-mailreader/Subscription_delete.do?host=mail.hotmail.com"> + Delete + </a> + + <a href="/struts2-mailreader/Subscription_edit.do?host=mail.hotmail.com"> + Edit + </a> + </td> + </tr> + <tr> + <td align="left"> + mail.yahoo.com + </td> + <td align="left"> + jquser + </td> + <td align="center"> + imap + </td> + <td align="center"> + false + </td> + <td align="center"> + <a href="/struts2-mailreader/Subscription_delete.do?host=mail.yahoo.com"> + Delete + </a> + + <a href="/struts2-mailreader/Subscription_edit.do?host=mail.yahoo.com"> + Edit + </a> + </td> + </tr> + </table> + <a href="/struts2-mailreader/Subscription_input.do">Add</a> + +<hr /> + + <p> + Now look back at the code used to generate this block. + </p> + <p> + Notice anything nifty? + </p> + <p> + How about that the markup between the iterator tag is + actually <em>simpler</em> than the markup that we would use to render one row of the + table? + </p> + <p> + Instead of using a qualified reference like "value=user.subscription[0].host", + we use the simplest possible reference: "value=host". + We didn't have to define a local variable, and reference that local in the loop code. + The reference to each item in the list is automatically resolved, no fuss, no muss. + </p> + <p> + Nice trick! + </p> + +<p> + The secret to this magic is the <strong>value stack</strong>. + Next to Interceptors, the value stack is probably the coolest thing there is about the + framework. + To explain the value stack, let's step back and start from the beginning. +</p> + +<p> + Merging dynamic data into static web pages is a primary reason + we create web applications. + The Java API has a mechanism that allows you to + place objects in a servlet scope (page, request, session, or + application), and then retrieve them using a JSP scriplet. + If the object is placed directly in one of the scopes, + a JSP tag or scriptlet can find that object by searching page scope and + then request scope, and session scope, and finally application scope. +</p> + +<p> + The value stack works much the same way, only better. + When you push an object on the value stack, + the public properties of that object become first-class properties of the stack. + The object's properties become the stack's properties. + If another object on the stack has properties of the same name, + the last object pushed onto the stack wins. (Last-In, First-Out.) +</p> + +<p> + When the iterator tag loops through a collection, + it pushes each item in the collection onto the stack. + The item's properties become the stack's property. + In the case of the Subscriptions, + if the Subscription has a public Host property, + then during that iteration, + the stack can access the same property. +</p> + +<p> + Of course, at the end of each iteration, the tag "pops" the item off the stack. + If we were to try and access the Host property later in the page, + it won't be there. +</p> + +<p> + When an Action is invoked, the Action class is pushed onto the value stack. + Since the Action is on the value stack, + our tags can access any property of the Action + as if it were an implicit property of the page. + The tags don't access the Action directly. + If a textfield tag is told to render the "Username" property, + the tag asks the value stack for the value of "Username", + and the value stack returns the first property it finds by that name, + on any object on the stack. +</p> + +<p> + The Validators also use the stack. + When validation fails on a field, + the value for the field is pushed onto the value stack. + As a result, if the client enters text into an Integer field, + the framework can still redisplay whatever was entered. + An invalid input value is not stored in the field (even if it could be). + The invalid input is pushed onto the stack for the scope of the request. +</p> + +<p> + The Subscription list uses another new tag: the <strong>param</strong> tag. + As tags go, "param" takes very few parameters of its own: just "name" and "value", + and neither is required. + Although simple, "param" is one of the most powerful tags the framework provides. + Not so much because of what it does, + but because of what "param" allows the other tags to do. +</p> + +<p> + Essentially, the "param" tag provides parameters to other tags. + A tag like "text" might be retrieving a message template with several replaceable + parameters. + No matter how many parameters are in the template, and no matter what they are named, + you can use the "param" tag to pass in whatever you need. +</p> + +<pre><code>pager.legend = Displaying {current} of {count} items matching {criteria}. +... +<s:text name="pager.legend"> + <s:<strong>param</strong> name="current" value="42" /> + <s:<strong>param</strong> name="count" value="314" /> + <s:<strong>param</strong> name="criteria" value="Life, the Universe, and Everything" /> +</s:text></code></pre> + +<p> + In the case of an "url" tag, + we can use "param" to create the query string. + A statement like this: +</p> + +<pre><code> + <s:url action="Subscription_edit"><s:param name="<strong>host" value="host</strong>"/></s:url>"> +</code></pre> + +<p> + can render a hyperlink like this: +</p> + +<pre><code> + <a href="/struts2-mailreader/Subscription_edit.do?<strong>host=mail.yahoo.com</strong>">Edit</a> +</code></pre> + +<!-- +<p> + At the foot of the Register page is a link for adding a subscription. + Let's wind up the tour by following the Add link and then logging off. + Like the link for creating a Registration, Add points to an "Edit" action, + namely "EditSubscription". +</p> +--> + +<p> + If a hyperlink needs more parameters, + you can use "param" to add as many parameters as needed. +</p> + +<h3> + <a name="Subscription" id="Subscription">Subscription</a> +</h3> + +<p> + If we follow one of the "Edit" subscription links on the Registration page, + we come to the Subscriptions page, + which displays the details of our description in a data-entry form. + Let's have a look at the Subscription configuration + and follow the bouncing ball from page to action to page. +</p> + +<hr /> +<h5>mailreader-support.xml Subscription element</h5> +<pre><code><action name="Subscription_*" method="{1}" class="mailreader2.Subscription"> + <result name="input">/pages/Subscription.jsp</result> + <result type="redirect-action">Registration_input</result> +</action></code></pre> +<hr /> + +<p> + The Edit link specified the Subscription action, + but also includes the qualifier <strong>_edit</strong>. + The wildcard notation tells the framework to use any characters given after "Subscription_" + as the name of a method to invoke on the Action class, + instead of the default execute method. + The "alternate" execute methods are called <strong>alias</strong> methods. +</p> + +<hr /> +<h5>Subscription edit alias</h5> +<pre><code>public String <strong>edit()</strong> { + <strong>setTask(Constants.EDIT);</strong>> + return find(); +} + +public String find() { + org.apache.struts.apps.mailreader.dao.Subscription + sub = findSubscription(); + if (sub == null) { + return ERROR; + } + <strong>setSubscription(sub);</strong> + return INPUT; +}</code></pre> +<hr /> + +<p> + The "edit" alias has two responsibilities. + First, it must set the Task property to "Edit". + The Subscription page will render itself differently + depending on the value of the Task property. + Second, "edit" must locate the relevant Subscription + and set it to the Subscription property. + If all goes well, "edit" returns the INPUT token, + so that the "input" result will be invoked. +</p> + +<p> + In the normal course, the Subscription should always be found, + since we selected the entry from a system-generated list. + If the Subscription is not found, + it would be because the database disappeared + or the request is being spoofed. + If the Subscription is not found, + edit returns the token for the global "error" result, + because this condition is unexpected. +</p> + +<p> + The business logic for the "edit" alias is a simple wrapper + around the MailReader DAO classes. +</p> + +<hr /> +<h5>MailreaderSupport findSubscription()</h5> +<pre><code>public Subscription <strong>findSubscription()</strong> { + return findSubscription(getHost()); +} + +public Subscription findSubscription(String host) { + Subscription subscription; + subscription = <strong>getUser().findSubscription(host);</strong> + return subscription; +}</code></pre> +<hr /> + +<p> + This code is very simple + and doesn't seem to provide much in the way of error handling. + But, that's OK. + Since the page is suppose to be entered from a link that we created, + we do expect everything to go right here. + But, if it doesn't, the global exception handler we defined in the + MailReader configuration will trap the exception for us. +</p> + +<p> + Likewise, the AuthentificationInterceptor will ensure that only clients + with a valid User object can try to edit a Subscription. + If the session expired, or someone bookmarked the page, + the client will be redirected to the Login page automatically. +</p> + +<p> + As a final layer of defense, we also configured a validator for Subscription, + to ensure that we are passed a Host parameter. +</p> + +<hr /> +<h5>Subscription-validation.xml</h5> +<pre><code><!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd";> +<validators> + <field name="<strong>host</strong>"> + <field-validator type="<strong>requiredstring</strong>"> + <message key="error.host.required"/> + </field-validator> + </field> +</validators></code></pre> +<hr /> + +<p> + By keeping routine safety precautions out of the Action class, + the all-important Action becomes smaller and easier to maintain. +</p> + +<p> + After setting the relevent Subscription object to the Subscription property, + the framework transfers control to the (you guessed it) Subscription page. +</p> + +<hr /> +<h5>Subscription.jsp</h5> +<pre><code><%@ page contentType="text/html; charset=UTF-8" %> +<%@ taglib prefix="s" uri="http://struts.apache.org/tags"; %> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" +"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> +<html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> + <head> + <s:if test="task=='Create'"> + <title><s:text name="subscription.title.create"/></title> + </s:if> + <s:if test="task=='Edit'"> + <title><s:text name="subscription.title.edit"/></title> + </s:if> + <s:if test="task=='Delete'"> + <title><s:text name="subscription.title.delete"/></title> + </s:if> + <link href="<s:url value="/css/mailreader.css"/>" rel="stylesheet" + type="text/css"/> + </head> + <body onLoad="self.focus();document.Subscription.username.focus()"> + + <s:actionerror/> + <s:form <strong>action="Subscription_save"</strong> validate="true"> + <strong><s:token /></strong> + <strong><s:hidden name="task"/></strong> + <strong><s:label key="username" name="user.username"/></strong> + + <s:if test="task == 'Create'"> + <s:textfield key="mailHostname" name="host"/> + </s:if> + <s:else> + <s:label key="mailHostname" name="host"/> + <s:hidden name="host"/> + </s:else> + + <s:if test="task == 'Delete'"> + <s:label key="subscription.username"/> + <s:label key="subscription.password"/> + <s:label key="subscription.type"/> + <s:label key="subscription.autoConnect"/> + <s:submit key="button.confirm"/> + </s:if> + <s:else> + <s:textfield key="subscription.username"/> + <s:textfield key="subscription.password"/> + <strong><s:select key="subscription.type" list="types"/></strong> + <strong><s:checkbox key="subscription.autoConnect"/></strong> + <s:submit key="button.save"/> + <s:reset key="button.reset"/> + </s:else> + + <s:submit action="Registration_input" + key="button.cancel" + onclick="form.onsubmit=null"/> + </s:form> + + <jsp:include page="Footer.jsp"/> + </body> +</html></code></pre> +<hr /> + +<p> + As before, we'll discuss the tags and attributes that are new to this page: + "token", "hidden", "label", "select", and "checkbox". +</p> + +<p> + The <strong>token</strong> tag works with the Token Session Interceptor to foil double + submits. + The tag generates a key that is embedded in the form and cached in the session. + Without this tag, the Interceptor can't work it's magic. +</p> + +<p> + The <strong>hidden</strong> tag embeds the Task property into the form. + When the form is submitted, + the Subscription_save action will use the Task property to decide + whether to insert or update the form. +</p> + +<p> + The <strong>label</strong> renders a "read only" version of a property, + suitable for placement in the form. + In Edit or Delete mode, we want the Host property to be immutable, + since it is used as a key. (As unwise as that might sound.) + In Delete mode, all of the properties are immutable, + since we are simply confirming the delete operation. +</p> + +<p> + Saving the best for last, the Subscription form utilizes two more interesting + tags, "select" and "checkbox". +</p> + +<p> + Unsurprisingly, the <strong>select</strong> tag renders a select control, + but the tag does so without requiring a lot of markup or redtape. +</p> + +<pre><code><s:select key="subscription.type" <strong>list="types"</strong> /> +</code></pre> + +<p> + The interesting attribute of the "select" tag is "list", + which, in our case, specifies a value of "types". + If we take another look at the Subscription action, + we can see that it implements an interface named Preparable + and populates a Types property in a method named "prepare". +</p> + +<hr /> +<h5>Subscription-validation.xml</h5> +<pre><code>public class <strong>Subscription</strong> extends MailreaderSupport + <strong>implements Preparable</strong> { + + private Map types = null; + public Map <strong>getTypes()</strong> { + return types; + } + + public void <strong>prepare()</strong> { + Map m = new LinkedHashMap(); + m.put("imap", "IMAP Protocol"); + m.put("pop3", "POP3 Protocol"); + types = m; + setHost(getSubscriptionHost()); + } + + // ... </code></pre> +<hr /> + +<p> + The default Interceptor stack includes the <strong>PrepareInterceptor</strong>, + which observes the Preparable interface. +</p> + +<hr /> +<h5>PrepareInterceptor</h5> +<pre><code>public class <strong>PrepareInterceptor</strong> extends AroundInterceptor { + + protected void after(ActionInvocation dispatcher, String result) throws Exception { + } + + protected void before(ActionInvocation invocation) throws Exception { + Object action = invocation.getAction(); + <strong>if (action instanceof Preparable) { + ((Preparable) action).prepare();</strong> + } + } +}</code></pre> + +<p> + The PrepareInterceptor ensures that the "prepare" method will always be called + before "execute" or an alias method is invoked. + We use "prepare" to setup the list of items for the select list to display. + We also transfer the Host property from our Subscription object + to a local property, where it is easier to manage. +</p> + +<h4> + <a name="Subscription.java" id="Subscription.java">Subscription.java</a> +</h4> + +<p> + Like many applications, the MailReader uses mainly String properties. + One exception is the AutoConnect property of the Subscription object. + On the HTML form, the AutoConnect property is represented by a checkbox. +</p> + +<p> + When writing web applications, the checkbox can be a tricky control. + The Subscription object has a boolean AutoConnect property, + and the checkbox simply has to represent its state. + The problem is, if you clear a checkbox, the browser client will not submit <em>anything</em>. + Nada. Zip. + It is as if the checkbox control never existed. + The HTTP protocol has no way to affirm "false". + If the control is missing, we need to figure out it's been unclicked. +</p> + +<p> + In Struts 1, + we use the <code>reset</code> method to work around checkbox issues. + In Struts 2, checkbox state is handled automatically. + The framework can detect when a checkbox tag has not been sent back, + and when that happens, + a default "false" value is used for the checkbox value. + No worries, mate. +</p> + +<p> + If we press the SAVE button, + the form will be submitted to the Subscription_save action. + Since the save method needs some additional validation, + we can add a validation file. +</p> + +<hr /> +<h5>Subscription-Subscription_save-validation.xml</h5> +<pre><code><!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" + "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd";> +<validators> + <field name="<strong>host</strong>"> + <field-validator type="<strong>requiredstring</strong>"> + <message key="error.host.required"/> + </field-validator> + </field> +</validators></code></pre> +<hr /> + +<p> + The validators follow the same type of inheritance path as the classes. + SubscriptionSave extends Subscription, + so when Subscription_save is validated, + the Host property specified by "Subscription-validation.xml" will also be required. +</p> + +<p> + If validation succeeds, the <code>save</code> method of Subscription will fire. +</p> + +<hr /> +<h5>Subscription</h5> + +<pre><code>public String <strong>save</strong>() throws Exception { + + if (Constants.DELETE.equals(getTask())) { + <strong>removeSubscription</strong>(); + } + + if (Constants.CREATE.equals(getTask())) { + <strong>copySubscription(</strong>getHost()); + } + + saveUser(); + return SUCCESS; +}</code></pre> +<hr /> + +<p> + The <strong>save</strong> method uses the Task property to handle + the special cases of deleting and creating, + and then updates the state of the User object. +</p> + +<p> + The <strong>removeSubscription</strong> method calls the DAO facade, + and then updates the application state. +</p> + +<hr /> +<h5>removeSubscription</h5> +<pre><code>public void <strong>removeSubscription</strong>() throws Exception { + getUser().removeSubscription(getSubscription()); + getSession().remove(Constants.SUBSCRIPTION_KEY); +}</code></pre> +<hr /> + +<p> + The <strong>copySubscription</strong> method is a bit more interesting. + The MailReader DAO layer API includes some immutable fields + that can't be set once the object is created. + Because key fields are immutable, + we can't just create a Subscription, let the framework populate all the fields, + and then save it when we are done -- because some fields can't be populated, + except at construction. +</p> + +<p> + One workaround would be to declare properties on the Action + for all the properties we need to pass to the Subscription or User objects. + When we are ready to create the object, + we could pass the new object values from the Action properties. +</p> + +<p> + Another workaround is to declare only the immutable properties on the Action, + and then use what we can from the domain object. +</p> + +<p> + This implementation of the MailReader utilizes the second alternative. + We define User and Subscription objects on our base Action, + and add other properties only as needed. +</p> + +<p> + To add a new Subscription or User, + we create a blank object to capture whatever fields we can. + When this "input" object returns, we create a new object, + setting the immutable fields to appropriate values, + and copy over the rest of the properties. +</p> + +<hr /> +<h5>copySubscription</h5> +<pre><code>public void <strong>copySubscription</strong>(String host) { + Subscription input = getSubscription(); + Subscription sub = createSubscription(host); + if (null != sub) { + <strong>BeanUtils.setValues</strong>(sub, input, null); + setSubscription(sub); + setHost(sub.getHost()); + } +}</code></pre> +<hr /> + +<p> + Of course, this is not a preferred solution, + but merely a way to work around an issue in the MailReader DAO API + that would not be easy for us change. +</p> + +<h4>Subscription Submit</h4> + +<p> + When we pressed the SAVE button, there was one step that we overlooked. + The Mailreader application uses a "double submit" guard to keep people + from clicking the SAVE button multiple times and submitting the form again. +</p> + +<p> + To add the double-submit guard, we can change the actions default processing + stack to <code>user-submit</code>. + But, we don't want to just copy and paste the other action settings from + the main Subscription action. + What we can do is put the subscription actions in their own package, + so that they can share result types. +</p> + +<hr /> +<h5>mailreader-support.xml</h5> +<pre><code><!-- ... --> +</package> + +<package name="subscription" namespace="/" extends="mailreader-support"> + + <global-results> + <result name="input">/Subscription.jsp</result> + <result type="redirect-action">Registration_input</result> + </global-results> + + <action name="Subscription_save" method="save" class="mailreader2.Subscription"> + <interceptor-ref name="user-submit" /> + </action> + + <action name="Subscription_*" method="{1}" class="mailreader2.Subscription" /> + +</package> + +<package name="wildcard" namespace="/" extends="mailreader-support"> + + <action name="*" class="mailreader2.MailreaderSupport"> + <result>/{1}.jsp</result> + </action> + +</package> +}</code></pre> +<hr /> + +<p> + Aftering a successful save, + the Subscription Action will return "success", + and the framework will redirect us back to Registration input. +</p> + +<h3>Summary</h3> +<p> + At this point, we've booted the application, logged on, + reviewed a Registration record, and edited a Subscription. + Of course, there's more, but from here on, it is mostly more of the same. + The full source code for MailReader is + <a href="http://svn.apache.org/viewvc/struts/struts2/trunk/apps/mailreader/";> + available online</a> + and in the distribution. +</p> + +<p> + Enjoy! +</p> +</blockquote> +</body> +</html>
http://git-wip-us.apache.org/repos/asf/struts-examples/blob/0677ec5c/pom.xml ---------------------------------------------------------------------- diff --git a/pom.xml b/pom.xml deleted file mode 100644 index 0965639..0000000 --- a/pom.xml +++ /dev/null @@ -1,95 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!-- -/* - * $Id$ - * - * Licensed to the Apache Software Foundation (ASF) under one - * or more contributor license agreements. See the NOTICE file - * distributed with this work for additional information - * regarding copyright ownership. The ASF licenses this file - * to you under the Apache License, Version 2.0 (the - * "License"); you may not use this file except in compliance - * with the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, - * software distributed under the License is distributed on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - * KIND, either express or implied. See the License for the - * specific language governing permissions and limitations - * under the License. - */ ---> -<project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> - <modelVersion>4.0.0</modelVersion> - <parent> - <groupId>org.apache.struts</groupId> - <artifactId>struts2-apps</artifactId> - <version>2.5-SNAPSHOT</version> - </parent> - - <artifactId>struts2-mailreader</artifactId> - <packaging>war</packaging> - <name>Struts 2 Mail Reader Webapp</name> - - <dependencies> - - <dependency> - <groupId>javax.servlet</groupId> - <artifactId>servlet-api</artifactId> - <scope>provided</scope> - </dependency> - - <dependency> - <groupId>${project.groupId}</groupId> - <artifactId>struts-mailreader-dao</artifactId> - <version>1.3.5</version> - </dependency> - - <!-- Logging --> - <dependency> - <groupId>org.apache.logging.log4j</groupId> - <artifactId>log4j-core</artifactId> - <version>${log4j2.version}</version> - </dependency> - <dependency> - <groupId>org.apache.logging.log4j</groupId> - <artifactId>log4j-jcl</artifactId> - <version>${log4j2.version}</version> - </dependency> - - </dependencies> - - <build> - <resources> - <resource> - <directory>src/main/java</directory> - <includes> - <include>**/*.xml</include> - <include>**/*.properties</include> - </includes> - </resource> - </resources> - <plugins> - <plugin> - <groupId>org.mortbay.jetty</groupId> - <artifactId>jetty-maven-plugin</artifactId> - <version>8.1.16.v20140903</version> - <configuration> - <stopKey>CTRL+C</stopKey> - <stopPort>8999</stopPort> - <scanIntervalSeconds>10</scanIntervalSeconds> - <webAppSourceDirectory>${basedir}/src/main/webapp/</webAppSourceDirectory> - <webAppConfig> - <contextPath>/struts2-mailreader</contextPath> - <descriptor>${basedir}/src/main/webapp/WEB-INF/web.xml</descriptor> - </webAppConfig> - </configuration> - </plugin> - </plugins> - </build> - <properties> - <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> - </properties> -</project>
