try {
    login(username, password);
} catch (BadLoginException) {
      ActionErrors errors = new ActionErrors();
      errors.add("login", new ActionError("bad. login"));
      return errors;
}

2.  Implement processExceptions in RequestProcessor.

protected ActionForward processException(HttpServ-letRequest request,
     HttpServletResponse response,
     Exception exception,
     ActionForm form,
     ActionMapping mapping)
   throws IOException, ServletException {
     if (exception instanceof BadLoginException) {
...
}

<global-exceptions>
   <exception
     key="bad.login"
     type="com.jdjexample.BadLoginException"
     handler="com.jdjexample.BadLoginExceptionHandler"/>
</global-exceptions>

Error handling is a vital part of any application robustness and security, and each application must discern requirements about how to deal with errors. Often, these requirements will include logging security relevant errors to provide forensics information after attacks and comply with traceability stipulations in compliance guidelines. Struts lets errors be handled cleanly both in and outside of the code, with multiple points to implement custom code for unique requirements.

Struts and Cross-Cutting Security Concerns
Often, applications have security requirements that affect all resources, such as guarantees about privacy, or auditing requirements. Rather than try to apply the correct logic in each individual component, it's often helpful to have an "intercepting" class that funnels all the invocations and performs a common set of routines. This way, changes to overall functionality can be isolated to a small area. Struts has several different places where cross-cutting security concerns can be implemented, each with its own particular benefits.

ActionServlet
ActionServlet is the primary servlet in the Struts framework, and handles all requests to Struts Actions. In Struts 1.0, ActionServlet was the class to extend to change the handling of all requests to actions; however, much of the functionality of ActionServlet was refactored to the RequestProcessor class. This lets sub-application modules handle requests differently and promotes abstraction between the processing of raw HTTP requests and Struts-specific request processing, which should happen in RequestProcessor. Typically ActionServlet should only be extended if other extension points can't provide the functionality needed.

RequestProcessor
The RequestProcessor class is where most of the per-request processing takes place. There are many different methods that can be overridden here, but some have very direct security relevance:

1. processRoles(): This method should be overridden for any action-level access control that must be programmatic (for instance, if the application doesn't use JAAS).
2. processNoCache(): This method should be overridden to tag the response as "no-cache" to avoid security vulnerabilities associated with locally caching content.
3. processException(): This method should do any special exception handling that can't be done declaratively.
4. processValidate(): This method should do any special validation that can't be done declaratively.

Base Action
By defining a base Action class that all other actions extend, security concerns can be addressed in the perform method and all other action classes would call the super. The disadvantage here is that all actions must extend this action, but this is a viable alternative to using a request processor.

Servlet Filter
The Filter class (javax.servlet.Filter) isn't Struts-related, but can be used to intercept and handle requests. Servlet Filters have the advantage of intercepting all (or some subset of) requests, not just those based on actions; if this functionality is necessary, then filters may be appropriate. An interesting use of Servlet Filters with respect to security is the security filter project (securityfilter.sourceforge.net) that emulates container-managed security, but alleviates problems with flexibility and portability. However, extending RequestProcessor is typically a cleaner solution because it centralizes the application logic in the Struts framework and requires less maintenance than using two separate libraries.

Conclusion
Application security is a problem that affects projects from the business goals down to the code implementation. Despite the increasing amount of knowledge and expertise available to the development community, many homegrown security solutions are used in place of established best practices. The Struts framework offers developers easy and effective security mechanisms that, when applied correctly, can significantly improve an application's overall security. While this article discusses some common issues, it's always important to consider unique security requirements and leverage best practices to suit the needs of the project as well as any included frameworks.