Why to chose Struts 2

Sripad
[email protected]
 Struts2
• Struts and webwork has joined together to
develop the Struts 2 Framework.
• Struts 2 Framework is very extensible and elegant
for the development of enterprise web
application of any size.
• Easy plugins - Add framework extensions by
dropping in a JAR. No manual configuration
required! Bundled plugins add support for GWT,
JasperReports, JFreeChart, Spring, Hibernate and
more ...
 Request Lifecycle in Struts 2 applications

1. User Sends request: User sends a request to the server for some
resource.
2. FilterDispatcher determines the appropriate action: The
FilterDispatcher looks at the request and then determines the
appropriate Action.
3. Interceptors are applied: Interceptors configured for applying the
common functionalities such as workflow, validation, file upload etc.
are automatically applied to the request.
4. Execution of Action: Then the action method is executed to perform
the database related operations like storing or retrieving data from
the database.
5. Output rendering: Then the Result renders the output.
6. Return of Request: Then the request returns through the
interceptors in the reverse order. The returning request allows us to
perform the clean-up or additional processing.
7. Display the result to user: Finally the control is returned to the
servlet container, which sends the output to the user browser.
 Feature Struts 1 Struts 2
An Struts 2 Action may implement
an Action interface, along with other
interfaces to enable optional and
Struts 1 requires Action classes to
custom services. Struts 2 provides a
extend an abstract base class. A
base ActionSupport class to
Action classes common problem in Struts 1 is
implement commonly used interfaces.
programming to abstract classes
Albeit, the Action interface
instead of interfaces.
is not required. Any POJO object with
a execute signature can be used as an
Struts 2 Action object.
Struts 1 Actions are singletons and
must be thread-safe since there will Struts 2 Action objects are instantiated
only be one instance of a class to for each request, so there are no
handle all requests for that Action. thread-safety issues. (In practice,
The singleton strategy places servlet containers generate many
Threading Model
restrictions on what can be done throw-away objects per request, and
with Struts 1 Actions and requires one more object does not impose a
extra care to develop. Action performance penalty or impact
resources must be thread-safe or garbage collection.)
synchronized.
 Feature Struts 1 Struts 2
Struts 2 Actions are not coupled to a
container. Most often the servlet
contexts are represented as simple
Struts 1 Actions have dependencies
Maps, allowing Actions to be tested in
on the servlet API since the
isolation. Struts 2 Actions can still
Servlet HttpServletRequest and
access the original request and
Dependency HttpServletResponse is passed to
response, if required. However, other
the execute method when an
architectural elements reduce or
Action is invoked.
eliminate the need to access the
HttpServetRequest or
HttpServletResponse directly.
A major hurdle to testing Struts 1
Struts 2 Actions can be tested by
Actions is that the execute method
instantiating the Action, setting
exposes the Servlet API. A third-
Testability properties, and invoking methods.
party extension, Struts TestCase,
Dependency Injection support also
offers a set of mock object for
makes testing simpler.
Struts 1.
 Feature Struts 1 Struts 2
Struts 2 uses Action properties as
input properties, eliminating the need
Struts 1 uses an ActionForm object for a second input object. Input
to capture input. Like Actions, all properties may be rich object types
ActionForms must extend a base which may have their own properties.
class. Since  other JavaBeans cannot The Action properties can can be
be used as ActionForms, developers accessed from the web page via the
often create redundant classes to taglibs. Struts 2 also supports the
Harvesting Input
capture input. DynaBeans can used ActionForm pattern, as well as POJO
as an alternative to creating form objects and POJO Actions. Rich
conventional ActionForm classes, object types, including business or
but, here too, developers may be domain objects, can be used as
redescribing existing JavaBeans.  input/output objects. The
ModelDriven feature simplifies taglb
references to POJO input objects. 

Struts 1 integrates with JSTL, so it Struts 2 can use JSTL, but the
uses the JSTL EL. The EL has basic framework also supports a more
Expression
object graph traversal, but relatively powerful and flexible expression
Language
weak collection and indexed language called "Object Graph
property support. Notation Language" (OGNL).
 Feature Struts 1 Struts 2
Struts 2 uses a "ValueStack"
technology so that the taglibs can
access values without coupling your
Struts 1 uses the standard JSP view to the object type it is rendering.
Binding values into
mechanism for binding objects into The ValueStack strategy allows reuse
views
the page context for access. of views across a range of types which
may have the same property name
but different property types. 

Struts 1 ActionForm properties are

usually all Strings. Struts 1 uses Struts 2 uses OGNL for type
Commons-Beanutils for type conversion. The framework includes
Type Conversion
conversion. Converters are per- converters for basic and common
class, and not configurable per object types and primitives.
instance.
 Feature Struts 1 Struts 2
Struts 1 supports manual validation Struts 2 supports manual validation
via a validate method on the via the validate method and the
ActionForm, or through an XWork Validation framework. The
extension to the Commons Xwork Validation Framework supports
Validation
Validator. Classes can have different chaining validation into sub-properties
validation contexts for the same using the validations defined for the
class, but cannot chain to properties class type and the
validations on sub-objects. validation context.
Struts 1 supports separate Request Struts 2 supports creating different
Processors (lifecycles) for each lifecycles on a per Action basis via
Control Of Action
module, but all the Actions in the Interceptor Stacks. Custom stacks can
Execution
module must share the same be created and used with different
lifecycle. Actions, as needed.