1. Extension using plugin. In this type of extension a custom class will have to implement org.apache.struts.action.PlugIn interface which has the init and destroy which are invoked during application startup and shutdown respectively. Such class will also have to be specified in struts-config.xml as a
2. The struts configuration classes can also be extended. The classes are in the package org.apache.struts.config are in-memory representations of the struts-config.xml
3. The ActionServlet itself can be extended by extending org.apache.struts.action.ActionServlet and one or more methods can be overridden. Such extension also requires change in the webapp deployment descriptor (web.xml):
4. Though ActionServlet can be extended its not the most prefered way for extension since most of the request processing behaviour is done by RequestProcessor. RequestProcessor class is based on Template Method Design pattern where a sequence of methods are called from the Process method. The RequestProcessor class can be extended for a CustomRequestProcessor and necessary methods can be overridden with desired functionality, the prefered method for overriding ins processPreprocess(). A real-time example of this can be found on one of my earlier posts here. In this extension appropriate class name of the extended processor must be specified using the
5. Extending Base Action class. This type of extension is highly helpful to provide common functionality required by all (or set of) Action classes of an application. In this type, the Action class is extended and methods that are required in common by most classes are specified and this class is extended by the rest of regular Action classes instead of the regular Action class. Helper methods for logging, user-lookup, basic validations can be included in such classes.