It is a flexible control layer based on technologies like Java Beans, XML, Java Servlets, and others. With the aid of this framework, you may establish an environment that is extendable and based on tried-and-true design principles for apps.
It is a flexible, attractive framework that can be used to build web applications suitable for business usage. This framework supports the entire application lifecycle, from development to deployment to timely maintenance. It was previously known as "web work 2."
Comparing Struts 1 and Struts 2:
- Action Classes are the primary distinction between Struts 1 and Struts 2. It is required to extend an abstract base class in Struts 1. This is a pretty typical issue with Struts 1, as programming is done to abstract classes rather than interfaces. To support extra and customized services, Struts 2 may implement an Action interface in addition to a number of other interfaces. However, using Action interfaces is not required; any POJO object with an execute signature can be used as an Action object.
- Because Struts 1 Actions are singletons and only one instance of a class will be handling all requests for that Action, there must be thread safety issues. Therefore, action resources need to be synchronized or thread-safe. Since action objects are created for each and every request in Struts 2, thread safety is not a significant concern.
- Configuration files are another significant distinction between Struts 1 and Struts 2. In Struts 2, the most popular configuration file is struts.xml, but Struts 1 uses struts-config.xml as well.
- Servlet dependency is another distinction between Struts 1 and Struts 2. Because the HttpServletRequest and HttpServletResponse are supplied to the execute method when an action is invoked, the Struts 1 action is dependent on the Servlet API. Struts 2 eliminates the need to access HttpServletRequest and HttpServletResponse by allowing actions to be tested independently from the other architectural components.
- Testability is the following point. Testing Struts 1 Action is a significant challenge because the execute method in Struts 1 exposes the Servlet API. A collection of dummy objects are provided via an extension Struts Test Case. Struts 2 makes it simple to test actions by instantiating them, calling methods, and setting properties.
- Struts 1 uses the JSTL EL since it incorporates JSTL. The EL supports object graph traversal but has limited support for index and collection properties. Struts 2 employs JSTL, but it also offers Object Graph Notation Language, a more adaptable and potent expressive language (OGNL).
- An ActionForm object is used in Struts 1 to collect input. All ActionForms in this case needs to extend a base class. Because other JavaBeans cannot be utilized as ActionForms, the developers write redundant classes to capture input. DynaBeans can be used as an alternative to standard Action classes, but they're also being used by developers to re-explain JavaBeans that already exist. Struts 2 does away with the necessity for a second input object by using Action properties as input properties. Using taglib, the webpage may access the Action properties. POJO Actions and POJO form objects are also supported by Struts 2.
- JSP is used in Struts1 to bind objects to the page. We employ ValueStack technology for a similar purpose in Struts 2. With the use of this technology, views from a variety of kinds that may have a different property type but the same property name can be reused.
- The type of conversion is the following significant distinction. OGNL is used for type conversion in Struts 2, as opposed to Commons Beanutils in Struts 1. The basic and common object types and primitives are used by Struts 1 and Struts 2, respectively.
- In Struts, one manual validation is supported by utilizing the common validator's extension or the validate function on the Action form. The validate function and the XWork validation framework both provide manual validation in Struts 2.
- Struts 1 supports distinct request lifecycles for each module, but Struts 2 supports different life cycles based on the action. All actions in a module should follow the same lifespan in Struts 1, whereas Struts 2 allows for the creation of custom stacks and their use with varied actions.
- Action Servlet is the front controller in Struts 1, whereas Filter Dispatcher is the front controller in Struts 2.
- Struts 1 has a number of tag libraries, including HTML, Bean, and others. Instead of having several tag libraries, Struts 2 only has one.
Struts 2 now has lots of new features. Among them are:
- An AJAX theme was added to Struts 2 to create more dynamic web applications.
- It allows for the use of annotations to configure Action classes.
- It is simple to integrate with Hibernate and Spring.
- Its design is more straightforward.
- It makes testability simpler.
- Checkboxes in Struts 2 do not need specific handling for incorrect values.
- Struts 2 does not require manual configuration; extensions are simply dropped into a jar to be added.
- It has excellent support for a variety of view alternatives, including Freemarker, JSP, Velocity, and others.
- In Struts 2, changing tags is simple.
If You want to learn more about struts in the most efficient way, Kindly check this out!!!