Struts 1 vs Struts 2

If you have worked with Java then choosing versions should not come to you as a
surprise. One might wonder how the JDKs have evolved over the years and how every
application that was built using a particular version of JDK would be obsolete by the time
the application was fully deployed.

Any application you use will always have versions and with each version increase the
features and advantages of the newer version should by right increase too. Struts is not an
exception. When struts was initially released the struts 1 was quite popular for quite some
time. The current release Struts 2 has many differences from the struts 1. This article
describes the differences between struts 1 and struts and offers a comparison chart
between them.

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
Action base ActionSupport class to
common problem in Struts 1 is
classes implement commonly used
programming to abstract classes
interfaces. Albeit, the Action
instead of interfaces.
interface is not required. Any POJO
object with a execute signature can
be used as an Struts 2 Action object.
Threading Struts 1 Actions are singletons and Struts 2 Action objects are
Model must be thread-safe since there will instantiated for each request, so there
only be one instance of a class to are no thread-safety issues. (In
handle all requests for that Action. practice, servlet containers generate
The singleton strategy places many throw-away objects per
restrictions on what can be done request, and one more object does
with Struts 1 Actions and requires not impose a performance penalty or
extra care to develop. Action impact garbage collection.)
resources must be thread-safe or
 synchronized.
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
on the servlet API since the
in isolation. Struts 2 Actions can still
Servlet HttpServletRequest and
access the original request and
Dependency HttpServletResponse is passed to the
response, if required. However, other
execute method when an Action is
architectural elements reduce or
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 Struts
makes testing simpler.
1.
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
class. Since other JavaBeans cannot properties. The Action properties can
be used as ActionForms, developers be accessed from the web page via
Harvesting often create redundant classes to the taglibs. Struts 2 also supports the
Input capture input. DynaBeans can used ActionForm pattern, as well as POJO
as an alternative to creating form objects and POJO Actions.
conventional ActionForm classes, Rich object types, including business
but, here too, developers may be or 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
uses the JSTL EL. The EL has basic
Expression
object graph traversal, but relatively
Language
weak collection and indexed
property support.
Binding Struts 1 uses the standard JSP
values into mechanism for binding objects into
views the page context for access.
Struts 2 can use JSTL, but the
framework also supports a more
powerful and flexible expression
language called "Object Graph
Notation Language" (OGNL).
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.

Struts 1 ActionForm properties are

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