How can I 'chain' Actions?
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:


/* 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");
}
}



/* 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");
}
}


Then you can chain together these two actions with
the Struts configuration as shown in the following excerpt:


...
<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>
...


Here we are assuming you are using a suffix-based (.do) servlet mapping, which is recommended since module support requires it. When you send your browser to the web application and name the action A.do (i.e. http://localhost:8080/app/A.do) it will execute AAction.execute(), which will then forward to the "success" mapping.
This causes the execution of BAction.execute() since the entry for "success" in the configuration file uses the .do suffix.
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.
As a rule, chaining Actions is not 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.
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.

Declarative Exception Handling
If you have developed web applications long enough, you will realize a recurring pattern emerges: when the backend (e.g. the EJB tier) throws you an exception, you nearly always need to display an error page corresponding to the type of that exception. Sooner or later, you will come up with a mechanism to use a lookup table (e.g. an HashMap) to lookup an error page from the exception class.
Struts 1.1 now provides a similar but more powerful mechanism to declare exception handling. In Struts 1.1, you can declare in the struts-config.xml the associations between an exception class and an exception handler. Using the default exception handler included in Struts, you can also specify the path of the error pages. With this information, Struts will automatically forward to the specified pages when an uncaught exception is thrown from an Action.
Like other facilities in Struts, the exception handlers are pluggable. You can write and define your own handler classes if needed.

Widget for blogger by Way2Blogging