struts  focus on service tier . it is view and model
independent . so it is service  tier ...

Feature Struts 1 Struts 2 
Action classes Struts 1 requires Action classes to extend 
an abstract base class. A common problem in Struts 1 is 
programming to abstract classes instead of interfaces. An 
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. Albeit, the Action 
interface is not required. Any POJO object with a execute 
signature can be used as an Struts 2 Action object. 
Threading Model 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. Struts 2 
Action objects are instantiated for each request, so there 
are no thread-safety issues. (In practice, servlet 
containers generate many throw-away objects per request, 
and one more object does not impose a performance penalty 
or impact garbage collection.) 
Servlet Dependency Struts 1 Actions have dependencies on 
the servlet API since the HttpServletRequest and 
HttpServletResponse is passed to the execute method when an 
Action is invoked. Struts 2 Actions 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. 
Testability A major hurdle to testing Struts 1 Actions is 
that the execute method exposes the Servlet API. A third-
party extension, Struts TestCase, offers a set of mock 
object for Struts 1. Struts 2 Actions can be tested by 
instantiating the Action, setting properties, and invoking 
methods. Dependency Injection support also makes testing 
simpler. 
Harvesting Input 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.
 Struts 2 uses Action properties as input properties, 
eliminating 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 taglb references to POJO 
input objects.
 
Expression Language Struts 1 integrates with JSTL, so it 
uses the JSTL EL. The EL has basic object graph traversal, 
but relatively weak collection and indexed property 
support. Struts 2 can use JSTL, but the framework also 
supports a more powerful and flexible expression language 
called "Object Graph Notation Language" (OGNL). 
Binding values into views Struts 1 uses the standard JSP 
mechanism for binding objects into the page context for 
access. 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.
 
Type Conversion Struts 1 ActionForm properties are usually 
all Strings. Struts 1 uses Commons-Beanutils for type 
conversion. Converters are per-class, and not configurable 
per instance. Struts 2 uses OGNL for type conversion. The 
framework includes converters for basic and common object 
types and primitives. 
Validation 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. 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. 
Control Of Action Execution Struts 1 supports separate 
Request Processors (lifecycles) for each module, but all 
the Actions in the module must share the same lifecycle. 
Struts 2 supports creating different lifecycles on a per 
Action basis via Interceptor Stacks. Custom stacks can be 
created and used with different Actions, as needed.

1.  Servlet Dependency:

Actions in Struts1 have dependencies on the servlet API 
since the HttpServletRequest and HttpServletResponse 
objects are passed to the execute method when an Action is 
invoked but in case of Struts 2, Actions are not container 
dependent because they are made simple POJOs. In struts 2, 
the servlet contexts are represented as simple Maps which 
allows actions to be tested in isolation. Struts 2 Actions 
can access the original request and response, if required. 
However, other architectural elements reduce or eliminate 
the need to access the HttpServetRequest or 
HttpServletResponse directly.

2.  Action classes

Programming the abstract classes instead of interfaces is 
one of design issues of struts1 framework that has been 
resolved in the struts 2 framework. 
Struts1 Action classes needs to extend framework dependent 
abstract base class. But in case of Struts 2 Action class 
may or may not implement interfaces to enable optional and 
custom services. In case of Struts 2 , Actions are not 
container dependent because they are made simple POJOs. 
Struts 2 provides a base ActionSupport class to implement 
commonly used interfaces. Albeit, the Action interface is 
not required. Any POJO object with an execute signature can 
be used as an Struts 2 Action object.

3.  Validation

Struts1 and Struts 2 both supports the manual validation 
via a validate method.
Struts1 uses validate method on the ActionForm, or 
validates through an extension to the Commons Validator. 
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.

4.  Threading Model

In Struts1, Action resources must be thread-safe or 
synchronized. So Actions are singletons and thread-safe, 
there should 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 Struts1 Actions and 
requires extra care to develop. However in case of Struts 
2, Action objects are instantiated for each request, so 
there are no thread-safety issues. (In practice, servlet 
containers generate many throw-away objects per request, 
and one more object does not impose a performance penalty 
or impact garbage collection.)

5.  Testability

Testing Struts1 applications are a bit complex. A major 
hurdle to test Struts1 Actions is that the execute method 
because it exposes the Servlet API. A third-party 
extension, Struts TestCase, offers a set of mock object for 
Struts1. But the Struts 2 Actions can be tested by 
instantiating the Action, setting properties and invoking 
methods. Dependency Injection support also makes testing 
simpler. Actions in struts2 are simple POJOs and are 
framework independent,  hence testability is quite easy in 
struts2.

6.  Harvesting Input

Struts1 uses an ActionForm object to capture input. And all 
ActionForms needs to extend a framework dependent base 
class. JavaBeans cannot be used as ActionForms, so the 
developers have to create redundant classes to capture 
input. 
However Struts 2 uses Action properties (as input 
properties independent of underlying framework) that 
eliminates the need for a second input object, hence 
reduces redundancy. Additionally in struts2, 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. Even rich 
object types, including business or domain objects, can be 
used as input/output objects. 

7.  Expression Language

Struts1 integrates with JSTL, so it uses the JSTL-EL. The 
struts1 EL has basic object graph traversal, but relatively 
weak collection and indexed property support. Struts 2 can 
also use JSTL, however it supports a more powerful and 
flexible expression language called "Object Graph Notation 
Language" (OGNL).

8.  Binding values into views

In the view section, Struts1 uses the standard JSP 
mechanism to bind objects (processed from the model 
section) into the page context to access. However 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 the reuse 
of views across a range of types which may have the same 
property name but different property types.

9.  Type Conversion

Usually, Struts1 ActionForm properties are all Strings. 
Struts1 uses Commons-Beanutils for type conversion. These 
type converters are per-class and not configurable per 
instance. However Struts 2 uses OGNL for type conversion. 
The framework includes converters for basic and common 
object types and primitives.

10.  Control Of Action Execution

Struts1 supports separate Request Processor (lifecycles) 
for each module, but all the Actions in a module must share 
the same lifecycle. However Struts 2 supports creating 
different lifecycles on a per Action basis via Interceptor 
Stacks. Custom stacks can be created and used with 
different Actions as needed.

our servlet class extending ActionServlet class

using requestProcessor by which we can customize 
ActionServlet class

please give detail ans with example if possible.

You can make your own ActionServlet by extending 
RequestProcessor class and overriding its methods. The 
example is given below....

package com.visualbuilder;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.RequestProcessor;

 public class CustomRequestProcessor extends    
RequestProcessor {

 public boolean processPreprocess(HttpServletRequest 
request, HttpServletResponse response) {

 System.out.println("Called the preprocess method before 
processing the request");
        return super.processPreprocess(request,response);
        }
}
 The following is web.xml file u should change it accoringly

<?xml version="1.0" encoding="UTF-8"?><web-app 
version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-
app_2_4.xsd"><servlet>    <servlet-name>action</servlet-
name>    <servlet-
class>com.visualbuilder.CustomActionServlet</servlet-
class>    <init-param>        <param-name>config</param-
name>        <param-value>/WEB-INF/struts-config.xml</param-
value>    </init-param>    <load-on-startup>2</load-on-
startup></servlet><servlet-mapping>    <servlet-
name>action</servlet-name>    <url-pattern>*.do</url-
pattern></servlet-mapping><welcome-file-list>    <welcome-
file>index.jsp</welcome-file></welcome-file-list></web-app>

we need to override processPreprocess(resquest,response)
method of RequestProcessor class to customize action servlet

its for request processor

Yes, you can write anything you want. But the *.do is the 
best practice used for servlet action.

yes we can write like this also

yes, we can write anything. but the fact is we have to
follow certain standards while writing programs. thats why
most of them prefer *.do

yes, we can write any thing instead of *.do. but using *.do 
id preferable but not mandator.

Yes, we can restore the last session. Let me know which 
technologies are you using? For example: check the naukri 
website.

hi ds is rajender .we hav uniq jsessionid cookie.if the 
container remember our session so we set session time in 
web.xml or in our application 

web.xml:
 <session-config>
    <session-timeout>200</session-timeout>
 </session-config>
                   

no ,Request processor creates only one instance of an Actin 
class

No, There is only one instance for an Action class in an 
application.

no,Action class is Thread Safe i.e request Processor 
creates only one instance for one Action class and one 
apllcation..

No having multiple references to action class means having
multiple controllers which violates the MVC design rules.

Hi,
Creating multiple instances for Actionservlet in struts1.x 
is not possible but there is a possibility in struts2.x .
But as of nowStruts 1.X is not supports this concept.




Thanks
Gangadhar

Hi,

ServletContext: ServletContext is a view of webapplication, 
there will be only one servletcontext for one 
webapplication. It acts as shared memoty area, all the 
components of a webapplication can access the data from  
servletcontext object.

ServletConfig:  ServletConfig will be specific to each 
servlet. If your webapplication contains 20 servlets then, 
there will be 20 servletsconfig objects.

Servlet Context: Servlet Context defines a set of methods
that a servlet uses to communicate with its servlet container.

Servlet Config: A servlet configuration object used by a
servlet container passes information to a servlet during
initialization.

Servlet Context -> It is one for the web application.
Servlet Config -> It is one for the Servlet.

I think Struts Action class is not Thread Safe
For more of these, please visit
http://freesourceutilityhelp.googlepages.com
http://question2answer.googlepages.com
http://context2designpatterns.googlepages.com

Thanks

Yes struts is not only thread safe but also thread 
dependent.Because its run in light weigth component and 
from the orignial action class.

as my nowladge Actionclass is thread safe.

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.


Struts 2 Action objects are instantiated for each request,
so there are no thread-safety issues. (In practice, servlet
containers generate many throw-away objects per request, and
one more object does not impose a performance penalty or
impact garbage collection.)

Yes struts is threadsafe. and light weight component also

digester

I think it is DOM becoz Struts configure file follows the 
tree model

it's SAX parser we use, to parse the Struct-Config.xml file.

just give the right answer ????????????

The Struts Console software uses an XML parser (JDOM + 
Xerces) to read in Struts config files.

am in confusion.. plz clarify..

please give exact answer.

Xerces is the parser which struts-config.xml is parsed with

I am in confusion give me right answer. But i think it's 
SAX parser

Action Servlet is parsing in to strutsconfig.xml

Can you give me the right answer........SAX OR DOM

SAX Parser is used to parse the xml file because basically 
it is for the ActionServlet to read the xml file rather 
than writing something into the struts-config xml file 
just the action servlet has to read the file and construts 
the module config object for the one time and load it
so as SAX Parser is basically for reading and doing some 
search operation Struts uses this aproach intelligently.

Digester is used to parse struts-config.xml

http://www.onjava.com/pub/a/onjava/2002/10/23/digester.html

The Digester class parser the XML document. The Digester
framework comes with 10 prepackaged "rules," which cover
most of the required tasks when unmarshalling XML (such as
creating a bean or setting a bean property), but each user
is free to define and implement his or her own rules, as
necessary.

Plz i am unable get the correct answer.Which one is the 
right answer.Help me in telling the correct answer.

The  documents  used  to struts is small . so parsing 
     with  DOM  most probable this because it fast convert
    the  document in tree wich fast to access ..

process of creating , invoking , destroying the servlet is
known as "life cycle of struts". here three methods are
involved 

1.init() :

Total intialization part of servlet ll be there in this .

2.service() :

Actual Bussiness code ll be there  in this method

3.destroy() :

just destroying the servlet  .

In life cycle of struts there r several part are there 

ActionServlet
Struts-config.xml
RequestProceser
formBean
Action class

There are many steps, 

1. After getting the request from the client, the 
ActionServlet invokes the goGet() or doPost() method, in 
which there is a invokation of process() method.This method 
desides the module.

2. Action servlet dispatches the request to RequestProcesor 
class which does some core works of ActionServlet.Then 
invokes the appropriate Action class.

3. Action class does main business logic and data accessing 
(communicating with Moedl) thru execute() method and which 
returns the ActionForward object.

4. In b/w the form field validations happens in form bean.

5. Depends upon the value of ActionForward object the view 
is decided to display.(output)


4. Form bean is invoked for form field validation,

The request is given to Action Servlet i.e; doGet or 
doPost.
ActionServlet with the help of request uri locates one of 
the RequestProcessor and dispatch the request to 
RequestProcessor i.e; process method on RequestProcessor is 
called InRequestProcessor.

It processes content type.
processes Locale.
processes actionPath.
processes actionMapping.
processes formBean.
processes action.
Error handling.

After processing action(i.e; execute method) depending on 
the results locate the path to view(with the help of 
ActionMapping) and dispatch the request to the located 
path.

When the Framework is loaded, it first loaded the Web.xml 
file. Then from the Servlet tag of Web.xml, it identifies 
the ActionServlet(or the Struts-Cofig.xml). Then from 
welcome-file tag of Struts-Cofig.xml, it identifies the 
first JSP page and runs it. Then when the request comes 
through that jsp, from acion-mappings tag of Struts-
Cofig.xml it identifies the request, through path tag
(request name) and input tag (jsp name), through name tag 
it identifies which bean is needed to access the data and 
through type tag it identifies which Action should be 
invoked. Then through the forward tag it identifies to 
which jsp it has to forward the response.

Sorry in the previous answer I made one mistake, welcome-
file-list is located in web.xml not in Struts-cofig.xml