Explore topic-wise InterviewSolutions in .

We need to use ITEXT. A OPEN source library for java. Please refer SOURCEFORGE SITE for SAMPLE servlet examples.

We need to use iText. A open source library for java. Please refer sourceforge site for sample servlet examples.

Using SERVLETCONTEXT, We can ACCESS data from its environment. Servlet CONTEXT is common to all Servlets so all Servlets SHARE the INFORMATION through ServeltContext.

Using ServletContext, We can access data from its environment. Servlet context is common to all Servlets so all Servlets share the information through ServeltContext.

The getRequestDispatcher(String path) method of ServletRequest interface accepts parameter the path to the resource to be INCLUDED or forwarded to, which can be RELATIVE to the request of the calling servlet. If the path begins with a "/" it is interpreted as relative to the current context root.

The getRequestDispatcher(String path) method of ServletContext interface cannot accepts relative paths. All path must sart with a "/" and are interpreted as relative to curent context root. If the resource is not available, or if the server has not IMPLEMENTED a RequestDispatcher object for that type of resource, getRequestDispatcher will return null. Your servlet should be PREPARED to deal with this condition.

The getRequestDispatcher(String path) method of ServletRequest interface accepts parameter the path to the resource to be included or forwarded to, which can be relative to the request of the calling servlet. If the path begins with a "/" it is interpreted as relative to the current context root.

The getRequestDispatcher(String path) method of ServletContext interface cannot accepts relative paths. All path must sart with a "/" and are interpreted as relative to curent context root. If the resource is not available, or if the server has not implemented a RequestDispatcher object for that type of resource, getRequestDispatcher will return null. Your servlet should be prepared to deal with this condition.

Servelt can invoke other Web RESOURCES in TWO WAYS: indirect and direct.

Indirect Way : Servlet will return the resultant HTML to the browser which will point to another Servlet (Web resource)

Direct Way : We can call another Web resource (Servelt / Jsp) from Servelt program itself, by using RequestDispatcher OBJECT.

You can GET this object using getRequestDispatcher("URL") method. You can get this object from either a request or a Context.

Servelt can invoke other Web resources in two ways: indirect and direct.

Indirect Way : Servlet will return the resultant HTML to the browser which will point to another Servlet (Web resource)

Direct Way : We can call another Web resource (Servelt / Jsp) from Servelt program itself, by using RequestDispatcher object.

You can get this object using getRequestDispatcher("URL") method. You can get this object from either a request or a Context.

Method 1) By URL rewriting
Method 2) Using SESSION object
Getting Session form HttpServletRequest object
HttpSession session = request.getSession(TRUE);
Get a Value from the session
session.getValue(session.getId());
Adding values to session
cart = new Cart();
session.putValue(session.getId(), cart);
At the end of the session, we can inactivate the session by using the following command
session.invalidate();
Method 3) Using COOKIES
Method 4) Using hidden FIELDS.

Method 1) By URL rewriting
Method 2) Using Session object
Getting Session form HttpServletRequest object
HttpSession session = request.getSession(true);
Get a Value from the session
session.getValue(session.getId());
Adding values to session
cart = new Cart();
session.putValue(session.getId(), cart);
At the end of the session, we can inactivate the session by using the following command
session.invalidate();
Method 3) Using cookies
Method 4) Using hidden fields.

HTTP.

HTTP.

setContentType() METHOD MUST be SET.

setContentType() method must be set.

When first REQUEST CAME in for the servlet , Server will invoke init() method of the servlet. There after if any user request the servlet program, Server will directly executes the service() method. When Server want to remove the servlet from POOL, then it will EXECUTE the DESTROY() method.

When first request came in for the servlet , Server will invoke init() method of the servlet. There after if any user request the servlet program, Server will directly executes the service() method. When Server want to remove the servlet from pool, then it will execute the destroy() method.

GET Method : Using get method we can able to PASS 2K data from HTML All data we are PASSING to Server will be displayed in URL (request STRING).

POST Method : In this method we does not have any size limitation. All data passed to server will be hidden, User cannot able to see this info on the browser.

GET Method : Using get method we can able to pass 2K data from HTML All data we are passing to Server will be displayed in URL (request string).

POST Method : In this method we does not have any size limitation. All data passed to server will be hidden, User cannot able to see this info on the browser.

When we SPECIFIED method='POST' in HTML
< FORM name='SSS' method='POST' >

When we specified method='POST' in HTML
< form name='SSS' method='POST' >

When we specified method='GET' in HTML
Example : &LT; FORM name='SSS' method='GET'&GT;

When we specified method='GET' in HTML
Example : < form name='SSS' method='GET'>

A servlet can HANDLE multiple requests concurrently, and can SYNCHRONIZE requests. Servlets can forward requests to other SERVERS and servlets. Thus servlets can be used to balance LOAD AMONG several servers.

A servlet can handle multiple requests concurrently, and can synchronize requests. Servlets can forward requests to other servers and servlets. Thus servlets can be used to balance load among several servers.

Servlets executes on SERVERS. APPLETS executes on browser. Unlike applets, HOWEVER, servlets have no graphical user INTERFACE.

Servlets executes on Servers. Applets executes on browser. Unlike applets, however, servlets have no graphical user interface.

A GenericServlet has a service() method to handle REQUESTS.
HttpServlet extends GenericServlet ADDED new methods

• doGet()
• DOPOST()
• doHead()
• doPut()
• doOptions()
• DODELETE()
• doTrace() methods

Both these classes are abstract.

A GenericServlet has a service() method to handle requests.
HttpServlet extends GenericServlet added new methods

Both these classes are abstract.

SERVLET Interface is the central abstraction. All servlets implements this Servlet Interface EITHER direclty or indirectly ( may IMPLEMENT or extend Servlet Interfaces SUB classes or sub interfaces)

Servlet
|
Generic Servlet
|
HTTPSERVLET ( Class ) -- we will extend this class to handle GET / PUT HTTP requests
|
MyServlet

Servlet Interface is the central abstraction. All servlets implements this Servlet Interface either direclty or indirectly ( may implement or extend Servlet Interfaces sub classes or sub interfaces)

Servlet
|
Generic Servlet
|
HttpServlet ( Class ) -- we will extend this class to handle GET / PUT HTTP requests
|
MyServlet

Servlet is a script, which resides and executes on SERVER side, to CREATE DYNAMIC HTML. In servlet PROGRAMMING we will use java language. A servlet can handle MULTIPLE requests concurrently.

Servlet is a script, which resides and executes on server side, to create dynamic HTML. In servlet programming we will use java language. A servlet can handle multiple requests concurrently.

The auto-deployment feature checks the APPLICATIONS folder EVERY three seconds to DETERMINE whether there are any new applications or any changes to existing applications and then dynamically deploys these changes.

The auto-deployment feature is ENABLED for servers that run in development mode. To disable auto-deployment feature, use one of the following methods to PLACE servers in production mode:

•  In the Administration Console, click the name of the domain in the left pane, then select the Production Mode checkbox in the right pane.
• At the command line, include the following argument when starting the domain's Administration Server:

-Dweblogic.ProductionModeEnabled=true
Production mode is set for all WebLogic Server instances in a given domain.

The auto-deployment feature checks the applications folder every three seconds to determine whether there are any new applications or any changes to existing applications and then dynamically deploys these changes.

The auto-deployment feature is enabled for servers that run in development mode. To disable auto-deployment feature, use one of the following methods to place servers in production mode:

-Dweblogic.ProductionModeEnabled=true
Production mode is set for all WebLogic Server instances in a given domain.

The applications folder is INTENDED for applications that are not yet ready for a PRODUCTION ENVIRONMENT. WebLogic SERVER dynamically deploys the contents of the applications folder. Thestage folder (or a folder that you create for the same purpose) is for storing copies of deployment files that are ready for deployment in a production environment (deployments that use the stage orexternal_stage deployment modes).

The applications folder is intended for applications that are not yet ready for a production environment. WebLogic Server dynamically deploys the contents of the applications folder. Thestage folder (or a folder that you create for the same purpose) is for storing copies of deployment files that are ready for deployment in a production environment (deployments that use the stage orexternal_stage deployment modes).

The Load Order attribute controls the deployment order of standalone modules and applications relative to other modules and applications of the same type. For example, standalone EJBS with smaller Load Order values are deployed before those with HIGHER values.

Modules that are deployed as part of an ENTERPRISE APPLICATION (EAR file or directory) are deployed in the order in which they are specified in the application.xml deployment descriptor.

The Load Order attribute controls the deployment order of standalone modules and applications relative to other modules and applications of the same type. For example, standalone EJBs with smaller Load Order values are deployed before those with higher values.

Modules that are deployed as part of an Enterprise Application (EAR file or directory) are deployed in the order in which they are specified in the application.xml deployment descriptor.

Set -external_stage using weblogic.Deployer if you WANT to stage the APPLICATION yourself, and PREFER to COPY it to its TARGET by your own means.

Set -external_stage using weblogic.Deployer if you want to stage the application yourself, and prefer to copy it to its target by your own means.

Set the STAGING mode to -nostage (using weblogic.Deployer or the ADMINISTRATION CONSOLE) if you don't want to copy DEPLOYMENT files but want to deploy an application from its present location. All target servers must be ABLE to access the same set of deployment files.

Set the staging mode to -nostage (using weblogic.Deployer or the Administration Console) if you don't want to copy deployment files but want to deploy an application from its present location. All target servers must be able to access the same set of deployment files.

WebLogic Server allows you to select the LOAD order for APPLICATIONS. WebLogic Server deploys server-level resources (first JDBC and then JMS) before deploying applications. Applications are deployed in this order: connectors, then EJBs, then Web Applications. If the APPLICATION is an EAR, the individual components are loaded in the order in which they are DECLARED in the application.xml deployment descriptor.

WebLogic Server allows you to select the load order for applications. WebLogic Server deploys server-level resources (first JDBC and then JMS) before deploying applications. Applications are deployed in this order: connectors, then EJBs, then Web Applications. If the application is an EAR, the individual components are loaded in the order in which they are declared in the application.xml deployment descriptor.

There are many possible configurations and each has its own advantages and disadvantages. BEA WebLogic Server has no built-in LIMIT for the number of server instances that can reside in a cluster. Large, multi-processor servers such as Sun Microsystems, Inc. Sun ENTERPRISE 10000, therefore, can host very large clusters or multiple clusters.

In most cases, WebLogic Server clusters SCALE best when deployed with one WebLogic Server instance for every two CPUs. HOWEVER, as with all capacity planning, you should test the actual deployment with your target web APPLICATIONS to determine the optimal number and distribution of server instances.

There are many possible configurations and each has its own advantages and disadvantages. BEA WebLogic Server has no built-in limit for the number of server instances that can reside in a cluster. Large, multi-processor servers such as Sun Microsystems, Inc. Sun Enterprise 10000, therefore, can host very large clusters or multiple clusters.

In most cases, WebLogic Server clusters scale best when deployed with one WebLogic Server instance for every two CPUs. However, as with all capacity planning, you should test the actual deployment with your target web applications to determine the optimal number and distribution of server instances.

If a server fails and DNS continues to send requests to the unavailable MACHINE, this can waste bandwidth. For a Java client application, this problem occurs only during STARTUP. WebLogic Server caches the DNS entries and removes the unavailable ONES, to PREVENT the client from accessing a failed server twice.

Failed servers can be more of a problem for browser-based clients, because they always use DNS. To AVOID unnecessary DNS requests with browser-based clients, use a third-party load-balancer such as Resonate, BigIP, Alteon, and LocalDirector. These products mask multiple DNS addresses as a single address. They also provide more sophisticated load-balancing options than round-robin, and they keep track of failed servers to avoid routing unnecessary requests.

If a server fails and DNS continues to send requests to the unavailable machine, this can waste bandwidth. For a Java client application, this problem occurs only during startup. WebLogic Server caches the DNS entries and removes the unavailable ones, to prevent the client from accessing a failed server twice.

Failed servers can be more of a problem for browser-based clients, because they always use DNS. To avoid unnecessary DNS requests with browser-based clients, use a third-party load-balancer such as Resonate, BigIP, Alteon, and LocalDirector. These products mask multiple DNS addresses as a single address. They also provide more sophisticated load-balancing options than round-robin, and they keep track of failed servers to avoid routing unnecessary requests.

The WEBLOGIC SERVER cluster broadcasts the availability of a new server instance each time a new instance joins the cluster. Cluster-aware stubs also PERIODICALLY update their LIST of AVAILABLE server instances.

The WebLogic Server cluster broadcasts the availability of a new server instance each time a new instance joins the cluster. Cluster-aware stubs also periodically update their list of available server instances.

WebLogic Server uses TWO mechanisms to determine if a given server instance is UNAVAILABLE.
Each WebLogic Server instance in a cluster uses multicast to broadcast regular "heartbeat" messages that advertise its availability. By monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed. The other server instances will drop a server instance from the cluster, if they do not receive three consecutive heartbeats from that server instance.

WebLogic Server ALSO monitors socket errors to determine the availability of a server instance. For example, if server instance A has an OPEN socket to server instance B, and the socket unexpectedly closes, server A assumes that server B is OFFLINE.

WebLogic Server uses two mechanisms to determine if a given server instance is unavailable.
Each WebLogic Server instance in a cluster uses multicast to broadcast regular "heartbeat" messages that advertise its availability. By monitoring heartbeat messages, server instances in a cluster determine when a server instance has failed. The other server instances will drop a server instance from the cluster, if they do not receive three consecutive heartbeats from that server instance.

WebLogic Server also monitors socket errors to determine the availability of a server instance. For example, if server instance A has an open socket to server instance B, and the socket unexpectedly closes, server A assumes that server B is offline.

When the FAILURE occurs, the stub removes the failed server instance from its LIST. If there are no servers left in its list, the stubb uses DNS again to find a running server and obtain a current list of running instances. Also, the stub periodically refreshes its list of available server instances in the cluster; this allows the stub to TAKE advantage of new servers as they are ADDED to the cluster.

When the failure occurs, the stub removes the failed server instance from its list. If there are no servers left in its list, the stubb uses DNS again to find a running server and obtain a current list of running instances. Also, the stub periodically refreshes its list of available server instances in the cluster; this allows the stub to take advantage of new servers as they are added to the cluster.

By default, if a Managed Server is unable to connect to the specified Administration Server during STARTUP, it can RETRIEVE its configuration by READING a configuration file and other files directly. You cannot change the server's configuration until the Administration Server is available. A Managed Server that starts in this way is running in Managed Server Independence MODE.

By default, if a Managed Server is unable to connect to the specified Administration Server during startup, it can retrieve its configuration by reading a configuration file and other files directly. You cannot change the server's configuration until the Administration Server is available. A Managed Server that starts in this way is running in Managed Server Independence mode.

When you CREATE a DOMAIN, the Configuration Wizard prompts you to provide the username and password for an initial administrative user. If you create the domain in development mode, the wizard saves the username and encrypted password in a BOOT identity file. A WEBLOGIC Server instance can refer to a boot identity file during its startup process. If a server instance does not find such a file, it prompts you to enter credentials.

If you create a domain in PRODUCTION mode, or if you want to change user credentials in an existing boot identity file, you can create a new boot identity file.

When you create a domain, the Configuration Wizard prompts you to provide the username and password for an initial administrative user. If you create the domain in development mode, the wizard saves the username and encrypted password in a boot identity file. A WebLogic Server instance can refer to a boot identity file during its startup process. If a server instance does not find such a file, it prompts you to enter credentials.

If you create a domain in production mode, or if you want to change user credentials in an existing boot identity file, you can create a new boot identity file.

Two things have to be DONE for TOMCAT to ACKNOWLEDGE SSI scripts: 

1. Rename $CATALINA_BASE/server/lib/servlets-ssi.renametojar to $CATALINA_BASE/server/lib/servlets-ssi.jar. 

2. Uncomment the section of web.xml found in $CATALINA_BASE/conf/web.xml that DEALS with SSI. it looks like this when it is uncommented: 

<servlet>
<servlet-name>ssi</servlet-name>
<servlet-class>
org.apache.catalina.ssi.SSIServlet
</servlet-class>
<init-param>
<param-name>buffered</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>666</param-value>
</init-param>
<init-param>
<param-name>isVirtualWebappRelative</param-name>
<param-value>0</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>

Two things have to be done for tomcat to acknowledge SSI scripts: 

1. Rename $CATALINA_BASE/server/lib/servlets-ssi.renametojar to $CATALINA_BASE/server/lib/servlets-ssi.jar. 

2. Uncomment the section of web.xml found in $CATALINA_BASE/conf/web.xml that deals with SSI. it looks like this when it is uncommented: 

<servlet>
<servlet-name>ssi</servlet-name>
<servlet-class>
org.apache.catalina.ssi.SSIServlet
</servlet-class>
<init-param>
<param-name>buffered</param-name>
<param-value>1</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>expires</param-name>
<param-value>666</param-value>
</init-param>
<init-param>
<param-name>isVirtualWebappRelative</param-name>
<param-value>0</param-value>
</init-param>
<load-on-startup>4</load-on-startup>
</servlet>

After successfully installing Tomcat, you usually test it by loading http://localhost:8080 . The contents of that page are compiled into the index_jsp servlet. The page even warns against modifying the INDEX.jsp files for this reason. Luckily, it is quite easy to override that page. Inside $TOMCAT_HOME/conf/web.xml there is a section called <welcome-file-list> and it looks like this: 

<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
The default servlet attempts to load the index.* files in the ORDER listed. You may easily override the index.jsp file by CREATING an index.html file at $TOMCAT_HOME/webapps/ROOT. It's somewhat common for that file to contain a new static home page or a redirect to a servlet's main page. A redirect would LOOK like: 

<html>
<head>
<meta http-equiv="refresh" content="0;URL=http://mydomain.com/some/path/to/servlet/homepage/">
</head>
<body>
</body>
</html>
This change TAKES effect immediately and does not require a restart of Tomcat.

After successfully installing Tomcat, you usually test it by loading http://localhost:8080 . The contents of that page are compiled into the index_jsp servlet. The page even warns against modifying the index.jsp files for this reason. Luckily, it is quite easy to override that page. Inside $TOMCAT_HOME/conf/web.xml there is a section called <welcome-file-list> and it looks like this: 

<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
The default servlet attempts to load the index.* files in the order listed. You may easily override the index.jsp file by creating an index.html file at $TOMCAT_HOME/webapps/ROOT. It's somewhat common for that file to contain a new static home page or a redirect to a servlet's main page. A redirect would look like: 

<html>
<head>
<meta http-equiv="refresh" content="0;URL=http://mydomain.com/some/path/to/servlet/homepage/">
</head>
<body>
</body>
</html>
This change takes effect immediately and does not require a restart of Tomcat.

Follow the STANDARD INSTRUCTIONS for when the isapi_redirector.dll 

Configure IIS to use "integrated windows security" 

In server.xml, make SURE you disable tomcat AUTHENTICATION: 

<Connector port="8009" enableLookups="false" redirectPort="8443"
protocol="AJP/1.3"tomcatAuthentication="false" /&GT;

Follow the standard instructions for when the isapi_redirector.dll 

Configure IIS to use "integrated windows security" 

In server.xml, make sure you disable tomcat authentication: 

<Connector port="8009" enableLookups="false" redirectPort="8443"
protocol="AJP/1.3"tomcatAuthentication="false" />

• Use a ResourceBundle. See the Java docs for the specifics of how the ResourceBundle class works. Using this method, the properties file must go into the WEB-INF/classes DIRECTORY or in a jar file contained in the WEB-INF/lib directory.
• Another way is to use the method getResourceAsStream() from the ServletContext class. This allows you update the file without having to RELOAD the webapp as required by the first method. Here is an example code snippet, without any error trapping:

// Assuming you are in a Servlet EXTENDING HTTPSERVLET
// This will look for a file called "/more/cowbell.properties" relative
// to your servlet ROOT Context
InputStream is = getServletContext().getResourceAsStream("/more/cowbell.properties");
Properties p = new Properties();
p.load(is);
is.close();

• Use a ResourceBundle. See the Java docs for the specifics of how the ResourceBundle class works. Using this method, the properties file must go into the WEB-INF/classes directory or in a jar file contained in the WEB-INF/lib directory.
• Another way is to use the method getResourceAsStream() from the ServletContext class. This allows you update the file without having to reload the webapp as required by the first method. Here is an example code snippet, without any error trapping:

// Assuming you are in a Servlet extending HttpServlet
// This will look for a file called "/more/cowbell.properties" relative
// to your servlet Root Context
InputStream is = getServletContext().getResourceAsStream("/more/cowbell.properties");
Properties p = new Properties();
p.load(is);
is.close();

STRUTS FRAMEWORK is built on J2EE TECHNOLOGIES (JSP, Servlet, Taglibs), but it is itself not part of the J2EE standard.

Struts framework is built on J2EE technologies (JSP, Servlet, Taglibs), but it is itself not part of the J2EE standard.

A Struts action is an instance of a subclass of an Action class, which implements a portion of a Web APPLICATION and whose perform or execute method returns a forward.

An action can perform tasks such as validating a user name and password.

An action mapping is a CONFIGURATION file entry that, in general, associates an action name with an action. An action mapping can CONTAIN a reference to a form bean that the action can use, and can additionally define a list of local forwards that is visible only to this action.

An action servlet is a servlet that is started by the servlet container of a Web server to process a request that invokes an action. The servlet receives a forward from the action and asks the servlet container to pass the request to the forward's URL. An action servlet must be an instance of an

org.apache.struts.action.ActionServlet class or of a subclass of that class. An action servlet is the primary COMPONENT of the controller.

A Struts action is an instance of a subclass of an Action class, which implements a portion of a Web application and whose perform or execute method returns a forward.

An action can perform tasks such as validating a user name and password.

An action mapping is a configuration file entry that, in general, associates an action name with an action. An action mapping can contain a reference to a form bean that the action can use, and can additionally define a list of local forwards that is visible only to this action.

An action servlet is a servlet that is started by the servlet container of a Web server to process a request that invokes an action. The servlet receives a forward from the action and asks the servlet container to pass the request to the forward's URL. An action servlet must be an instance of an

org.apache.struts.action.ActionServlet class or of a subclass of that class. An action servlet is the primary component of the controller.

Perform method is the method which was deprecated in the STRUTS Version 1.1. In Struts 1.x, Action.perform() is the method called by the ActionServlet. This is typically where your business logic RESIDES, or at least the flow CONTROL to your JavaBeans and EJBs that handle your business logic. As we already mentioned, to support declarative exception HANDLING, the method signature changed in perform. Now execute just throws Exception. Action.perform() is now deprecated; however, the Struts v1.1 ActionServlet is smart enough to know whether or not it should CALL perform or execute in the Action, depending on which one is available.

Perform method is the method which was deprecated in the Struts Version 1.1. In Struts 1.x, Action.perform() is the method called by the ActionServlet. This is typically where your business logic resides, or at least the flow control to your JavaBeans and EJBs that handle your business logic. As we already mentioned, to support declarative exception handling, the method signature changed in perform. Now execute just throws Exception. Action.perform() is now deprecated; however, the Struts v1.1 ActionServlet is smart enough to know whether or not it should call perform or execute in the Action, depending on which one is available.

tiles-def.xml : tiles-def.xml is used as a configuration file for an appliction during tiles development You can define the layout /header /footer /body content for your View.

validation.xml : The validation.xml file is used to declare sets of validations that should be applied to Form BEANS.

Each Form Bean you want to validate has its own definition in this file Inside that definition, you specify the validations you want to apply to the Form Bean's fields.

Resourcebundle.properties : Instead of having hard-coded error messages in the framework, STRUTS Validator allows you to specify a key to a MESSAGE in the Application Resources. properties (or resourcebundle. properties) file that should be RETURNED if a validation FAILS.

tiles-def.xml : tiles-def.xml is used as a configuration file for an appliction during tiles development You can define the layout /header /footer /body content for your View.

validation.xml : The validation.xml file is used to declare sets of validations that should be applied to Form Beans.

Each Form Bean you want to validate has its own definition in this file Inside that definition, you specify the validations you want to apply to the Form Bean's fields.

Resourcebundle.properties : Instead of having hard-coded error messages in the framework, Struts Validator allows you to specify a key to a message in the Application Resources. properties (or resourcebundle. properties) file that should be returned if a validation fails.

STRUTS is not only thread-safe but thread-dependant. The RESPONSE to a request is handled by a light-weight Action object, RATHER than an individual servlet. Struts instantiates each Action class once, and allows other requests to be threaded through the original object. This core strategy conserves resources and provides the best POSSIBLE THROUGHPUT. A properly-designed application will exploit this further by routing related operations through a single Action.

Struts is not only thread-safe but thread-dependant. The response to a request is handled by a light-weight Action object, rather than an individual servlet. Struts instantiates each Action class once, and allows other requests to be threaded through the original object. This core strategy conserves resources and provides the best possible throughput. A properly-designed application will exploit this further by routing related operations through a single Action.

An abstract Action that dispatches to the subclass mapped execute method. This is useful in cases where an HTML FORM has MULTIPLE submit buttons with the same name. The button name is specified by the PARAMETER property of the CORRESPONDING ActionMapping.

An abstract Action that dispatches to the subclass mapped execute method. This is useful in cases where an HTML form has multiple submit buttons with the same name. The button name is specified by the parameter property of the corresponding ActionMapping.

Struts Flow is a port of Cocoon's CONTROL Flow to Struts to allow COMPLEX workflow, like multi-form wizards, to be easily implemented using continuations-capable JavaScript. It PROVIDES the ABILITY to describe the order of WEB pages that have to be sent to the client, at any given point in time in an application. The code is based on a proof-of-concept Dave Johnson put together to show how the Control Flow could be extracted from Cocoon.

Struts Flow is a port of Cocoon's Control Flow to Struts to allow complex workflow, like multi-form wizards, to be easily implemented using continuations-capable JavaScript. It provides the ability to describe the order of Web pages that have to be sent to the client, at any given point in time in an application. The code is based on a proof-of-concept Dave Johnson put together to show how the Control Flow could be extracted from Cocoon.

In Struts you can handle the exceptions in two ways:
a) DECLARATIVE EXCEPTION Handling: You can either define global exception handling tags in your struts-config.xml or define the exception handling tags within .. tag. 
EXAMPLE:

key="database.error.duplicate" 
PATH="/UserExists.jsp" 
TYPE="mybank.account.DuplicateUserException"/>
b) Programmatic Exception Handling: Here you can use try{}catch{} block to handle the exception. 

In Struts you can handle the exceptions in two ways:
a) Declarative Exception Handling: You can either define global exception handling tags in your struts-config.xml or define the exception handling tags within .. tag. 
Example:

key="database.error.duplicate" 
path="/UserExists.jsp" 
type="mybank.account.DuplicateUserException"/>
b) Programmatic Exception Handling: Here you can use try{}catch{} block to handle the exception. 

ActionMessage: A CLASS that encapsulates MESSAGES. Messages can be either global or they are specific to a PARTICULAR bean property.

Each individual message is described by an ActionMessage object, which contains a message key (to be looked up in an APPROPRIATE message resources database), and up to four placeholder arguments used for parametric substitution in the resulting message.

ActionErrors: A class that encapsulates the error messages being reported by the validate() method of an ActionForm. VALIDATION errors are either global to the entire ActionForm bean they are associated with, or they are specific to a particular bean property (and, therefore, a particular input field on the corresponding form).

ActionMessage: A class that encapsulates messages. Messages can be either global or they are specific to a particular bean property.

Each individual message is described by an ActionMessage object, which contains a message key (to be looked up in an appropriate message resources database), and up to four placeholder arguments used for parametric substitution in the resulting message.

ActionErrors: A class that encapsulates the error messages being reported by the validate() method of an ActionForm. Validation errors are either global to the entire ActionForm bean they are associated with, or they are specific to a particular bean property (and, therefore, a particular input field on the corresponding form).

Struts PROVIDES a number of tag libraries that helps to create view COMPONENTS easily. These tag libraries are:
a) Bean Tags: Bean Tags are used to access the BEANS and their PROPERTIES.
b) HTML Tags: HTML Tags provides tags for creating the view components LIKE forms, buttons, etc..
c) Logic Tags: Logic Tags provides presentation logics that eliminate the need for scriptlets.
d) Nested Tags: Nested Tags helps to work with the nested context.

Struts provides a number of tag libraries that helps to create view components easily. These tag libraries are:
a) Bean Tags: Bean Tags are used to access the beans and their properties.
b) HTML Tags: HTML Tags provides tags for creating the view components like forms, buttons, etc..
c) Logic Tags: Logic Tags provides presentation logics that eliminate the need for scriptlets.
d) Nested Tags: Nested Tags helps to work with the nested context.

CORE CLASSES of Struts FRAMEWORK are ActionForm, Action, ActionMapping, ActionForward, ActionServlet etc.

Core classes of Struts Framework are ActionForm, Action, ActionMapping, ActionForward, ActionServlet etc.

Struts Framework provides the FUNCTIONALITY to validate the FORM DATA. It can be use to validate the data on the users BROWSER as well as on the server side. Struts Framework emits the JAVA scripts and it can be used validate the form data on the client browser. Server side validation of form can be accomplished by sub classing your From Bean with DynaValidatorForm class.

Struts Framework provides the functionality to validate the form data. It can be use to validate the data on the users browser as well as on the server side. Struts Framework emits the java scripts and it can be used validate the form data on the client browser. Server side validation of form can be accomplished by sub classing your From Bean with DynaValidatorForm class.

An ActionForm is a JavaBean optionally associated with one or more ActionMappings. Such a bean will have had its properties initialized from the corresponding request parameters before the corresonding action's perform() method is called. When the properties of this bean have been POPULATED, but before the perform() method of the action is called, this bean's VALIDATE() method will be called, which gives the bean a chance to verify that the properties submitted by the user are correct and VALID. If this method finds problems, it returns an error messages object that encapsulates those problems, and the controller servlet will return control to the corresponding input form. OTHERWISE, the validate() method returns null(), indicating that everything is acceptable and the corresponding Action's perform() method should be called. This class must be subclassed in order to be instantiated. Subclasses should provide property getter and setter methods for all of the bean properties they wish to expose, plus OVERRIDE any of the public or protected methods for which they wish to provide modified functionality.

An ActionForm is a JavaBean optionally associated with one or more ActionMappings. Such a bean will have had its properties initialized from the corresponding request parameters before the corresonding action's perform() method is called. When the properties of this bean have been populated, but before the perform() method of the action is called, this bean's validate() method will be called, which gives the bean a chance to verify that the properties submitted by the user are correct and valid. If this method finds problems, it returns an error messages object that encapsulates those problems, and the controller servlet will return control to the corresponding input form. Otherwise, the validate() method returns null(), indicating that everything is acceptable and the corresponding Action's perform() method should be called. This class must be subclassed in order to be instantiated. Subclasses should provide property getter and setter methods for all of the bean properties they wish to expose, plus override any of the public or protected methods for which they wish to provide modified functionality.

An Action is an adapter between the contents of an incoming HTTP request and the corresponding business logic that should be executed to process this request. The controller (ActionServlet) will select an appropriate Action for each request, CREATE an instance (if necessary), and call the perform method. Actions must be programmed in a thread-safe manner, because the controller will share the same instance for multiple simultaneous requests. In this means you should design with the following items in mind:

• Instance and static variables MUST NOT be used to store information related to the state of a particular request. They MAY be used to share global RESOURCES across requests for the same action.

•  Access to other resources (JavaBeans, session variables, etc.) MUST be synchronized if those resources require protection. (Generally, however, resource classes should be designed to provide their own protection where necessary. When an Action instance is first created, the controller servlet will call setServlet() with a non-null argument to identify the controller servlet instance to which this Action is ATTACHED. When the controller servlet is to be SHUT down (or restarted), the setServlet() method will be called with a null argument, which can be used to CLEAN up any allocated resources in use by this Action.

An Action is an adapter between the contents of an incoming HTTP request and the corresponding business logic that should be executed to process this request. The controller (ActionServlet) will select an appropriate Action for each request, create an instance (if necessary), and call the perform method. Actions must be programmed in a thread-safe manner, because the controller will share the same instance for multiple simultaneous requests. In this means you should design with the following items in mind:

 Access to other resources (JavaBeans, session variables, etc.) MUST be synchronized if those resources require protection. (Generally, however, resource classes should be designed to provide their own protection where necessary. When an Action instance is first created, the controller servlet will call setServlet() with a non-null argument to identify the controller servlet instance to which this Action is attached. When the controller servlet is to be shut down (or restarted), the setServlet() method will be called with a null argument, which can be used to clean up any allocated resources in use by this Action.

ACTIONSERVLET provides the "controller" in the MODEL-View-Controller (MVC) design pattern for web applications that is commonly known as "Model 2". This nomenclature originated with a DESCRIPTION in the JavaServerPages Specification, version 0.92, and has persisted ever since (in the ABSENCE of a better NAME).Controller is responsible for handling all the requests.

ActionServlet provides the "controller" in the Model-View-Controller (MVC) design pattern for web applications that is commonly known as "Model 2". This nomenclature originated with a description in the JavaServerPages Specification, version 0.92, and has persisted ever since (in the absence of a better name).Controller is responsible for handling all the requests.

Struts is based on the MVC design pattern. Struts components can be categories into Model, View and CONTROLLER.

Model: Components like business logic / business processes and data are the part of Model.

View: JSP, HTML ETC. are part of View

Controller: ACTION Servlet of Struts is part of Controller components which works as front controller to HANDLE all the REQUESTS.

Struts is based on the MVC design pattern. Struts components can be categories into Model, View and Controller.

Model: Components like business logic / business processes and data are the part of Model.

View: JSP, HTML etc. are part of View

Controller: Action Servlet of Struts is part of Controller components which works as front controller to handle all the requests.

It implements Model-View-Controller pattern in the framework and it is an open source CODE. It saves time in design and IMPLEMENTATION of a web based APPLICATION DUE to this framework and pattern as I is highly robust, scalable and RELIABLE.

It implements Model-View-Controller pattern in the framework and it is an open source code. It saves time in design and implementation of a web based application due to this framework and pattern as I is highly robust, scalable and reliable.