Difference between Struts 1 and Struts 2?

Question

I had been using struts 2, but for few reasons i am shifting (back) to Struts 1 . I would like to know major diffrences between them like about programatic availabilities and general flows.

Answer 1

Let us see the component and functional differences between struts 1.x and struts 2.x

 In struts 1.x front controller is ActionServlet
    In 2.x front controller is FilterDispatcher

In struts 1.x we have RequestProcessor class
    In 2.x we have Interceptors instead RequestProcessor will see about this concept later just remember as of now

In struts 1.x we have multiple tag libraries like, html, logic, bean..etc
    In 2.x we do not have multiple libraries, instead we have single library which includes all tags

In struts 1.x the configuration fine name can be [any name].xml and we used to place in web-inf folder
    In 2.x the configuration file must be struts.xml only and this must be in classes folder

In struts 1.x we have form beans and Action classes separately
    In 2.x form bean, Action classes are combinedly given as Action class only, of course we can take separately if we want ;)

In struts 1.x properties file must be configured in struts-config.xml
    But in 2.x we need to configure our resource bundle(s) in struts.properties file

In struts 1.x we have programmatic and declarative validations only
    In 2.x we have annotations support too along with programmatic and declarative validations

Functional Differences

In struts 1.x declarative validations are done by using validation frame work
    In 2.x, declarative validations are done by using xwork2 frame work by webwork the reason being, its support valuations through Annotations

In struts 1.x an Action class is a single ton class, so Action class object is not a thread safe, as a programmer we need to make it as thread safe by applying synchronization
    In 2.x an Action class object will be created for each request, so it is by default thread safe, so we no need to take care about safety issues here

In struts 1.x we have only jsp as a view technology
    In 2.x we have support of multiple view technologies like velocity, Freemarker, jasper reports, jsp bla bla

In struts 1.x Action class is having servlet dependency, because in execute() method accepts req, res parameter right ! so.
    In 2.x Action class doesn’t have any servlet dependency, because its execute() method doesn’t accepts any parameters, however we can access all servlet objects with dependency injection

Answer 2

In http://www.java-samples.com you can find a quick and complete answer. In other words, if you can, forget Struts and use only Struts2...

This is the comparison table from the Programming Tutorials site, mentioned above:

The End-Of-Life Struts 1 release was introduced in December 2008 and is version 1.3.10. You can still get it and will still work, but there is no support or further development. You are on your own there.

Answer 3

Comparison of Struts 1 and 2 by the creators of Struts (Apache software foundation)

Comparing Struts 1 and Struts 2

Here is the content available at the above mentioned link, incase if they decide to change the link or remove the page in the future.

1. Action Classes
   

   • Struts 1
     Requires Action classes to extend an abstract base class. A common problem in Struts 1 is programming to abstract classes 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. Albeit, the Action interface is not required. Any POJO object with a execute signature can be used as a Struts 2 Action object.

2. Threading Model
   

   • Struts 1
     Actions are singletons and must be thread-safe since there will only be one instance of a class to handle all requests for that Action. The singleton strategy places restrictions on what can be done with Struts 1 Actions and 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. (In practice, servlet containers generate many throw-away objects per request, and one more object does not impose a performance penalty or impact garbage collection.)

3. 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. Most often the servlet contexts are represented as simple Maps, allowing Actions to be tested in isolation. 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.

4. Testability
   

   • Struts 1
     A major hurdle to testing Struts 1 Actions is that the execute method exposes the Servlet API. A third-party extension, Struts TestCase, offers a set of mock object for Struts 1.
   • 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.
     Struts 2 Actions can be tested by instantiating the Action, setting properties, and invoking methods. Dependency Injection support also makes testing simpler.

5. 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 redescribing 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 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.
6. Expression Languages
   
   • Struts 1
     Integrates with JSTL, so it uses the 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 "Object Graph Notation Language" (OGNL).
7. 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.
     
8. 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.
     
9. 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.
     
10. 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.