Difference Struts 1 Struts 2 framework
Some interviewer still ask this questions to just candidate knowledge about struts framework also to check if you have worked on both the versions or not.
| Struts 2 | Struts 1 |
| You could create any POJO class with execute operation that will be your Action object. Struts 2 also provide base ActionSupport class to implement commonly used interfaces but it’s not required can be used only by your choice. | You will have to extend an abstract base class to create your Action class. This was problem not using interface but extend an abstract class |
| Here Action objects are created for every request so that there are no thread safety issues. (Servlet containers generates many throw away objects for every request and extra object doesn’t impose performance issues or impact garbage collection) | Actions classes are single threaded singleton so there will be only one instance to handle all the requests for that Action. As its singleton it places restrictions so all Action resources must be explicitly synchronized or thread safe. |
| Actions classes not coupled to the container means it doesn’t uses servlet API HttpServletRequest and HttpServletResponse object. Servlet contexts been represented by simple Maps which allows Actions classes test simple. Actions classes could still access original request and response object if needed | Actions classes has dependencies on the servlet API because HttpServletRequest and HttpServletResponse object has been used in execute method whenever Action is invoked |
| Actions classes could be tested by instantiating Action object and setting its properties and invoking methods. DI (Dependency Injection) support makes testing easier | Testing of Action class is complex as execute method uses servlet API HttpServletRequest and HttpServletResponse object so for test you need third party extension, struts test-case which gives set of mock objects. |
| Action class properties can be use as input properties which eliminate need of second input object. Here input properties are rich object types that may have its own properties. Action properties could be accessed from web page via tag-libs. It also supports ActionForm pattern POJO Rich object types, POJO form objects including domain or business objects that can be used as input/output objects. Its Model Driven feature simplifies tag-lib references to the POJO input objects | It uses ActionForm objects to keep input fields. Again here like Action class, ActionForms should extend base class. Main bottleneck is other JavaBeans cannot used as ActionForms so programmers create redundant classes to capture input fields. DynaBeans could be used an alternative to creating conventional ActionForm classes but developers may have to re-describing existing JavaBeans classes |
| You can use JSTL (Optional) it supports more powerful, flexible expression language OGNL (Object Graph Notation Language) | It has relatively weak collection, indexed property support because of JSTL integration where it uses JSTL EL which has EL has basic object graph traversal |
| It use new ValueStack technology where tag-libs can be access values without coupling view to object type it’s rendering. This strategy allows reuse of the views across the range of types which could have same property name but different property types | It uses JSP mechanism to bind objects into page context for accessibility |
| It users OGNL for type conversion. Framework includes converters for common, primitives and basic object types | ActionForm class properties is usually Strings. It uses Commons-Beanutils for type conversion. Its not configurable per instance and converters are per-class basis |
| It uses manual validation via using validate method and using XWork Validation framework. Xwork Validation Framework supports chaining validation to sub properties by validations defined for properties class type and validation context | It do validation using validate method on ActionForm class if not then using extension to Commons Validator |
| It supports creating different life-cycles per Action class basis via Interceptor Stacks. Custom stacks could be created and used with different Actions whenever needed | It uses separate Request Processors (life-cycles) for each module and all Actions class in the module should share same life-cycle |
Reference:
