Is struts threadsafe ?

Yes

Struts is not only thread-safe but thread-dependent.

The response to a request is handled by a light-weight Action object, rather than an individual Servlet.

Struts instantiates each Action class once, and allows other requests to be threaded through the original object.

This core strategy conserves resources and provides the best possible throughput.

A properly-designed application will exploit this further by routing related operations through a single Action.

Which Design patterns are used in Struts framework ?

Design patterns used in Struts 1x

• MVC: Struts framework is based on Model 2 MVC pattern.
• FrontController : Provides a centralized controller (ActionServlet) for managing the handling of requests.
• Command pattern: Struts controller uses the Command design pattern.
• Adapter pattern: Action classes use the Adapter design pattern.
• Template pattern: The process() method of the RequestProcessor uses the Template method design pattern.
• Composite View: Used in Struts Tiles.
• Value Object (VO) / Context object: Form Beans that encapsulate the values entered on a form.
• Chain of Responsibility pattern (CoR): Request Processor  is composed using commons chain, which is an implementation of CoR pattern.
• Dispatcher View: Using ActionMapping to forward the flow to the View after performing some business logic from the action class.
• View Helper: Encapsulates logic that is not related to presentation formatting into Helper components.
• Service to Worker: Combines a Dispatcher component with the Front Controller and View Helper patterns.
• Synchronizer Token: This strategy addresses the problem of duplicate form submissions. Uses this strategy to control direct browser access to certain pages.

• Struts 2 uses Inversion of Control (IoC) pattern also known as dependency injection.

Tiles vs. Sitemesh

Tiles vs. Sitemesh

Whereas in tiles, you have to push the pages into the template file, SiteMesh pulls the requested page into the template.

While tiles, which works with templates, SiteMesh acts as a decorator around your HTML pages that go through the web-server.

Struts1x vs. Struts2x

Action classes

• Struts 1 requires Action classes to extend an abstract base class (instead of interfaces) 
• Struts 2 Action may implement an Action interface, along with other interfaces to enable optional and custom services. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Although Action / ActionSupport are not mandatory.
  Any POJO object with a execute signature can be used as an Struts 2 Action object.

Threading Model

• Struts 1 Actions are singletons and must be thread-safe since there will be only one instance of a class to handle all requests for that Action. It requires extra care to develop. Action resources must be thread-safe or synchronized. 

• Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.

Servlet Dependency

• Struts 1 Actions have dependencies on the servlet API since the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked.
• Struts 2 Actions are not coupled to a container. 
  Struts 2 Actions can still access the original request and response, if required. However, other architectural elements reduce or eliminate the need to access the HttpServetRequest or HttpServletResponse directly.

Testability

• Struts 1 execute method exposes the Servlet API and requires HTTPServletRequest and HTTPServletResponse
  A third-party extension, Struts TestCase, offers a set of mock object for Struts 1.     
• Struts 2 Actions can be tested by instantiating the Action, setting properties, and invoking methods.
  Dependency Injection support also makes testing simpler.

Harvesting Input

• Struts 1 uses an ActionForm object to capture input.
  Like Actions, all ActionForms must extend a base class.
  Since other JavaBeans cannot be used as ActionForms, developers often create redundant classes to capture input.
  DynaBeans can used as an alternative to creating conventional ActionForm classes, but, here too, developers may be re-describing existing JavaBeans.
• Struts 2 uses Action properties as input properties, eliminating the need for a second input object. Input properties may be rich object types which may have their own properties. 
  The Action properties can can be accessed from the web page via the taglibs.
  Struts 2 also supports the ActionForm pattern, as well as POJO form objects and POJO Actions. Rich object types, including business or domain objects, can be used as input/output objects. The ModelDriven feature simplifies taglb references to POJO input objects.

Expression Language

• Struts 1 integrates with JSTL, so it uses JSTL EL.
  The EL has basic object graph traversal, but relatively weak collection and indexed property support.     
• Struts 2 can use JSTL, but the framework also supports a more powerful and flexible expression language called OGNL (Object Graph Notation Language)

Binding values into views

• Struts 1 uses the standard JSP mechanism for binding objects into the page context for access.     
• Struts 2 uses a "ValueStack" technology so that the taglibs can access values without coupling your view to the object type it is rendering.
  The ValueStack strategy allows reuse of views across a range of types which may have the same property name but different property types.

Type Conversion

• Struts 1 ActionForm properties are usually all Strings. Struts 1 uses Commons-Beanutils for type conversion.
  Converters are per-class, and not configurable per instance.    
• Struts 2 uses OGNL for type conversion.
  The framework includes converters for basic and common object types and primitives.

Validation

• Struts 1 supports manual validation via a validate method on the ActionForm, or through an extension to the Commons Validator.
  Classes can have different validation contexts for the same class, but cannot chain to validations on sub-objects.     
• Struts 2 supports manual validation via the validate method and the XWork Validation framework. 
  The Xwork Validation Framework supports chaining validation into sub-properties using the validations defined for the properties class type and the validation context.

Control Of Action Execution

• Struts 1 supports separate Request Processors (lifecycles) for each module, but all the Actions in the module must share the same lifecycle.
• Struts 2 supports creating different lifecycles on a per Action basis via Interceptor Stacks.
  Custom stacks can be created and used with different Actions, as needed.

What are controller components and RequestProcessor ?

Controller

• responsible for intercepting and translating user input into actions to be performed by the model.
• responsible for selecting the next view based on user input and the outcome of model operations.
• receives the request from the browser, invoke a business operation and coordinating the view to return to the client. 
• implemented by a Java Servlet
• Centralized point of control for the web application

• In struts framework, the controller responsibilities are implemented by several different components like :  
• The ActionServlet Class 
• The RequestProcess or Class 
• The Action Class

 
RequestProcessor

The class org.apache.struts.action.requestProcessor process the request from the controller. You can sublass the RequestProcessor with your own version.

Flow

• Controller receives a client request
• It delegates the handling of the request to a helper class (Action class)
  This helper knows how to execute the business operation associated with the requested action.
  It acts as a bridge between a client-side user action and business operation.
• The Action class decouples the client request from the business model.
  This decoupling allows for more than one-to-one mapping between the user request and an action.
• The Action class also can perform other functions such as authorization, logging before invoking business operation.

What is DispatchAction and LookupDispatchAction ?

DispatchAction

• org.apache.struts.action.DispatchAction class
• lets you combine Struts actions into one class, each with their own method.
• allows multiple operation to mapped to the different functions in the same Action class.

Example

Create action class by extending it DispatchAction class and put multiple methods into it. Like :

public ActionForward create(ActionMapping mapping,  ActionForm form, 

  HttpServletRequest request, HttpServletResponse response) 

  throws IOException, ServletException { ...}

public ActionForward save(ActionMapping mapping, ActionFormform, 

  HttpServletRequest request, HttpServletResponse response) 

  throws IOException, ServletException { ...}

Specify the name of of the dispatch property as the "parameter" property of the action-mapping.

<action path="/reg/dispatch" type="app.reg.RegDispatch" 

        name="regForm" scope= "request" validate="true"

        parameter="dispatch"/>

Now, call this action by passing request parameter "dispatch" from the calling page.

URL ? dispatch = create

URL ? dispatch = save

LookupDispatchAction

• An abstract Action that dispatches to the subclass mapped execute method.
• Useful in cases where an HTML form has multiple submit buttons with the same name.
• The button name is specified by the parameter property of the corresponding ActionMapping.

Example

Put the multiple submit buttons with same names but different messages keys (message keys defined in message resources)

<html:form action="/test">

   <html:submit property="method">

      <bean: message key="button.add"/>

    </html:submit>

    <html:submit property="method">

      <bean:message key="button.delete"/>

    </html:submit>

</html:form>

Create action class by extending it LookupDispatchAction class.

Your subclass must implement both getKeyMethodMap and the methods defined in the map.

   public ActionForward add(...)  { ... }

   public ActionForward delete(...)   { ... }

   protected Map getKeyMethodMap() {

      Map map =  new HashMap();

      map.put("button.add", "add");

      map.put("button.delete", "delete");

      return map;

   }

Specify the name of of the dispatch property as the "parameter" property of the action-mapping.

<action path="/test" type="org.example.MyAction" name="MyForm" 

        scope="request" input="/test.jsp" parameter="method"/>

What is Struts Validator Framework ?

Struts Validator Framework

• provides the functionality to validate the form data
• can validate data on the users browser as well as on the server side.
• Client side : emits the javascript and it can be used to validate the form data on browser.
• Server side : subclass your Form bean with DynaValidatorForm class.
• comes integrated with Struts Framework ; No extra settings required.

Details of XML files used in Validator Framework 

• validator-rules.xml 
• defines the standard validation routines, which are reusable
• used in validation.xml to define the form specific validations

• validator.xml 
• defines the validations applied to a form bean

ActionForm vs. DynaActionForm vs. DynaValidatorForm

With a DynaActionForm, instead of writing classes that extend ActionForm, you define all your form beans as DynaActionForm, and define the properties for each form in the struts-config.xml file.

DynaValidatorForm will process validations defined in the Struts Validator Framework, whereas DynaActionForm will not.

They both require properties to be defined in the struts-config.xml file.

DynaActionForm

struts-config.xml

<form-beans >

   <form-bean name="exampleForm" type="org.apache.struts.action.DynaActionForm">

       <form-property name="age" 

                  type="java.lang.Integer" initial="23" />

       <form-property name="name"  

                  type="java.lang.String" initial="Adam Weisshaupt" />

    </form-bean>

</form-beans>

Use of DynaActionForm in Actions

DynaActionForm exampleForm = (DynaActionForm) form;

System.out.println(exampleForm.get("name"));

DynaValidatorForm

The form bean DynaValidatorForm is the dynamic variant of the ValidatorForm and offers the possibility to validate properties based on validation rules.

The form bean DynaValidatorForm uses the Struts validation capabilities using validation rules defined in XML files. Struts offers a wide choice of rules, you can all find in the file validator-rules.xml.

You configure the rules foreach property of a FormBean. 

These validations have to be written in the XML file (validation.xml)

struts-config.xml

<form-beans >

    <form-bean name="exampleForm" 

               type="org.apache.struts.validator.DynaValidatorForm">

       <form-property name="age" type="java.lang.Integer" />

       <form-property name="name" type="java.lang.String" />

    </form-bean>

</form-beans>

validation.xml

<form-validation>

   <formset>

       <form name="exampleForm">

          <field property="name" depends="required, minlength">

               <arg0 key="exampleForm.name" />

               <arg1 key="${var:minlength}" resource="false" />

               <var>

                   <var-name>minlength</var-name>

                   <var-value>3</var-value>

               </var>

         </field>

       </form>

    </formset>

</form-validation>