1). In Struts 1 it's mandatory to extend org.apache.struts.action.Action and implement execute() method which returns ActionForward and accept HttpServletRequest and HttpServletResponse.
Where as in 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. Any POJO object with a execute signature can be used as an Struts 2 Action object. Also execute() method returns String rather than returning ActionForward object. You can still use ActionSupport class or Action interface but those are completely optional.
2). 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.
In Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
3). Struts 1 Actions have dependencies on the servlet API because the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked.
Struts 2 removed the dependency of Action classes to Servlet API, Actions in Struts 2 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). 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.
Where as Struts 2 uses Action properties as input properties, which eliminate 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 taglib references to POJO input objects.
5). 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.
However, 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.
6). Also one main difference between Struts 1 and Struts 2 is on configuration files, earlier we used to configure Struts using struts-config.xml, but with Struts 2 you can use multiple configuration file, most commonly used as struts.xml. What is more important is declaration of Struts 2 Filter in web.xml e.g.
< filter >
< filter-name >struts2Fitler< /filter-name >
< filter-class >
org.apache.struts2.dispatcher.FilterDispatcher
< /filter-class >
< /filter >
< filter-mapping >
< filter-name >struts2Fitler< /filter-name >
< url-pattern >/*< /url-pattern >
< /filter-mapping >
Also, if you notice, instead of mapping this to *.do or *.action we have mapped it with *, which means all url pattern will be flown to struts2 filter.
7). In Struts 1, ActionServlet is considered as FrontController while in Struts 2 its Filter, which can be considered as front end controller.
8). Default location of the Single Configuration used in Struts 1 is the WEB-INF folder, whereas multiple configuration files can be used in struts 2 and should be put directly inside or subdirectories in WEB-INF/classes.
Where as in 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. Any POJO object with a execute signature can be used as an Struts 2 Action object. Also execute() method returns String rather than returning ActionForward object. You can still use ActionSupport class or Action interface but those are completely optional.
2). 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.
In Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
3). Struts 1 Actions have dependencies on the servlet API because the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked.
Struts 2 removed the dependency of Action classes to Servlet API, Actions in Struts 2 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). 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.
Where as Struts 2 uses Action properties as input properties, which eliminate 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 taglib references to POJO input objects.
5). 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.
However, 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.
6). Also one main difference between Struts 1 and Struts 2 is on configuration files, earlier we used to configure Struts using struts-config.xml, but with Struts 2 you can use multiple configuration file, most commonly used as struts.xml. What is more important is declaration of Struts 2 Filter in web.xml e.g.
< filter >
< filter-name >struts2Fitler< /filter-name >
< filter-class >
org.apache.struts2.dispatcher.FilterDispatcher
< /filter-class >
< /filter >
< filter-mapping >
< filter-name >struts2Fitler< /filter-name >
< url-pattern >/*< /url-pattern >
< /filter-mapping >
Also, if you notice, instead of mapping this to *.do or *.action we have mapped it with *, which means all url pattern will be flown to struts2 filter.
7). In Struts 1, ActionServlet is considered as FrontController while in Struts 2 its Filter, which can be considered as front end controller.
8). Default location of the Single Configuration used in Struts 1 is the WEB-INF folder, whereas multiple configuration files can be used in struts 2 and should be put directly inside or subdirectories in WEB-INF/classes.
Copyright © 2014 - ScrutinyByKHimaanshu
(k%2Bhimaanshu%2Bshukla).jpg)
.jpg)
%2B(2).JPG)
.jpg)
.jpg)
%2B(2).JPG)
%2B(1).png)
0 comments:
Post a Comment