Ch1 Struts1 vs Struts2.Shtml

8/8/2019 Ch1 Struts1 vs Struts2.Shtml

http://slidepdf.com/reader/full/ch1-struts1-vs-struts2shtml 1/4

Feature Struts 1 Struts 2

Action

classes

Struts1 extends the

abstract base class by

its action class. The

problem with struts1

is that it uses the

abstract classes rather

than interfaces.

While in Struts 2, an

Action class

implements an Action

interface, along with

other interfaces use

optional and custom

services. Struts 2

provides a base

ActionSupport class

that implements

commonly used

interfaces. Although an

Action interface is not

necessary, any POJO

object along with an

execute signature can

be used as an Struts 2

Action object.

Threading

Model

Struts 1 Actions are

singletons therefore

they must be thread-

safe because only one

instance of a class

handles all the

requests for that

Action. The singleton

strategy restricts to

Struts 1 Actions and

requires extra care to

make the action

resources thread safe

or synchronized while

developing an

application.

Struts 2 doesn't have

thread-safety issues as

Action objects are

instantiated for each

request. A servlet

container generates

many throw-away

objects per request, and

one more object does

not impose a

performance penalty or

impact garbage

collection.

Page 1 of 4Struts1 vs Struts2

10/31/2010http://www.roseindia.net/struts/struts1-vs-struts2.shtml



Servlet

Dependency

Actions are dependent

on the servlet API

because

HttpServletRequest

and

HttpServletResponse

is passed to the

execute method when

an Action is invoked

therefore Struts1.

Container does not

treat the Struts 2

Actions as a couple.

Servlet contexts are

typically represented as

simple Maps that allow

Actions to be tested in

isolation. Struts 2

Actions can still access

the original request and

response, if required.

While other

architectural elements

directly reduce or

eliminate the need to

access the

HttpServetRequest or

HttpServletResponse.

Testability

Struts1 application

has a major problem

while testing the

application because

the execute method

exposes the Servlet

API. Struts TestCase

provides a set of mock

object for Struts 1.

To test the Struts 2

Actions instantiate the

Action, set the

properties, and

invoking methods.

Dependency Injection

also makes testing

easier.

Struts 1 recieves an

input by creating an

ActionForm object.

Like the action

classes, all

ActionForms class

must extend a

ActionForm base

Struts 2 requires Action

properties as input

properties that

eliminates the need of a

second input object.

These Input properties

may be rich object

types, since they may





Harvesting

Input

class. Other

JavaBeans classes

cannot be used as

ActionForms, while

developers createredundant classes to

receive the input.

DynaBeans is the best

alternative to create

the conventional

ActionForm classes.

have their own

properties. Developer

can access the Action

properties from the

web page using thetaglibs. Struts 2 also

supports the

ActionForm pattern,

POJO form objects and

POJO Actions as well.

Expression

Language

Struts1 integrates with

JSTL, so it uses theJSTL EL. The EL has

basic object graph

traversal, but

relatively weak

collection and indexed

property support.

Struts 2 can use JSTL,

but the framework alsosupports a more

powerful and flexible

expression language

called "Object Graph

Notation

Language" (OGNL).

Binding

values into

views

Struts 1 binds objects

into the page context

by using the standard

JSP mechanism.

Struts 2 uses a

ValueStack technologyto make the values

accessible to the taglibs

without coupling the

view to the object to

which it is rendering.

The ValueStack

strategy enables us to

reuse views across a

range of types, having

same property name

but different property

types.

Struts 1 ActionForm

properties are almost





Type

Conversion

in the form of Strings.

Commons-Beanutils

are used by used by

Struts 1 for type

conversion.Converters are per-

class, which are not

configurable per

instance.

Struts 2 uses OGNL for

type conversion and

converters to convert

Basic and common

object types and

primitives as well.

Validation

Struts 1 uses manual

validation that is done

via a validate method

on the ActionForm, or

by using an extension

to the Commons

Validator. Classes can

have different

validation contexts for

the same class, while

chaining to

validations on sub-objects is not allowed.

Struts 2 allows manual

validation that is done

by using the validate

method and the XWork Validation framework.

The Xwork Validation

Framework allows

chaining of validations

into sub-properties

using the validations

defined for the

properties class type

and the validation

context.

Control Of

Action

Execution

Each module in Struts

1 has a separate

Request Processors

(lifecycles), while all

the Actions in the

module must share thesame lifecycle.

In Struts 2 different

lifecycles are created

on a per Action basis

via Interceptor Stacks.

Custom stacks are

created and used with

different Actions, as

required.s


10/31/2010http://www roseindia net/struts/struts1 vs struts2 shtml

Documents

Ch1 Struts1 vs Struts2.Shtml