Servlets

Web Application Structure

A Web application is a collection of many different types of files, a typical web application might include
among others
• Servlets
• HTML Pages
• Image, audio, video
• Java Server Pages (JSP Pages)
• A deployment descriptor and other configuration file.
The concept of web application was introduced in version 2.2 of the Java Servlet specification.
A web application is organized with a structured hierarchy of directories, with particular type of files stored in
particular directories.
These directories can then be packaged into a web application archive (WAR) file.
Directory Structure
The directory structure of a web application has two parts:
1. A directory WEB-INF that contains the resources that is not to be directly downloaded to a client. This
Directory is private the client does have direct access to the files in this directory.
The WEB-INF directory typically contains dynamic resources such as servlets, as well as configuration
files.
2. A directory that contains those resources that are intended to be publicly available. This includes all the
subdirectories of this directory, except of course for the private WEB-INF directory.
This Directory typically contains static resources such as HTML and image files.














MyWebApp – is the root directory of the web application.
Public resources – files in my MyWebApp (or subdirectories)
                               file in images folder (or subdirectories)
                               file in literature folder(or subdirectories)
Private resources – files contains within the WEB-INF directory. Resources that are
                                 Only accessible to the container.
A public resource is any file that is accessible to the client of the web application. Typical public resources
include:
• HTML, XML and JSP documents.
• Image, audio and video files.
• Java applets – classes as well as jar files containing applets.
• Microsoft office documents: world, Excel, etc.
Client browsers can download these resources unchanged and render them as required.
For example, when an HTML page includes an <APPLET> tag that refers to an applet in a jar file.
The web container delivers the JAR file to the client browser unchanged.
Typically, the container reads the static resources from the file system, and writes the contents directly to the
network connection. The interpretation of the contents of these resources is the responsibility of the client
browser. In order to help the browser render the file correctly, the container sends the MIME type of the file.
These MIME types can be set in the deployment descriptor of the web application.
Note: Although JSP pages are included as public resources in a web application; the container does not show
them directly to clients. The Container automatically converts JSP Page into Servlets.The Servlets is then
compiled and invoked to generate the response for the client.
However, since a JSP Page is often considered more to an HTML document than to a java class, JSP Pages are
also included under public resources.

Private Resources
Of course, there are certain resources that clients should not load directly. There may be files that the client
should not view, such as configuration files or they may be files that the container must perform some
processing on before sending the response to the client, like servlets. These private resources are stored in the
WEB-INF directory, or its subdirectories.
The Types of resources that clients should not download directly include:
• Servlets – These components include application logic, and possibly access to other resources such as
database. Any other file in the web application that servlets access directly.
• Resources that are meant for execution or use on the server side, such as java class file and JAR files
for classes used by your servlets.
• Temporary files created by your applications.
• Deployment descriptors and other configuration files.
These resources are private and as such are accessible only to their own web application and the container. In
order to accommodate private resources the web container requires the WEB-INF directory to be present in
your application. It your web application does not contain this directory it will not work.
The WEB-INF directories includes:
• A web.xml file. This is the deployment descriptor.
• A Subdirectory named classes. This directory is used to store server-side Java class files such as
servlets and other helper classes, structured according to the usual Java packaging rules.
• A lib subdirectory to contain JAR files used by the web application.

Advantage of the Structure
• Each application exists in a ‘sand-box’. The public and private resources of an application are
independent of any other application that the container may be running.
• When a new application is added to the J2EE server, we can simply add the appropriate context root
in the deploy tool of the reference implementation, without disturbing any other application.
• The Container knows where to look for classes. This means that you do not need to explicitly add
these classes and JAR files to the CLASSPATH.
• The difference between a conventional web server and a web container is that each web application
has its own document root.
• Similar to the public resources, Private resources of different web applications are stored in different
folders.
• According to the Servlet specification a container should load classes/JAR files of each web
application using a different class loader. it is for this reason that servlets, JSP Pages, and other
classes that are part of one web application cannot see classes in other application and therefore
cannot share static variables or singleton classes, for Example. This is easily achieved by the
structure discussed above.
Thus, even if you deployed the same web application twice (each mapping to a different URL) as for as
container is concerned they are two entirely different applications. such applications cannot share information.
As a result, web containers create a virtual partitioning of web applications within the container.

MyWebApp – is the root directory of the web application.
Public resources – files in my MyWebApp (or subdirectories)
                               file in images folder (or subdirectories)
                               file in literature folder(or subdirectories)
Private resources – files contains within the WEB-INF directory. Resources that are
                                 Only accessible to the container.
A public resource is any file that is accessible to the client of the web application. Typical public resources
include:
• HTML, XML and JSP documents.
• Image, audio and video files.
• Java applets – classes as well as jar files containing applets.
• Microsoft office documents: world, Excel, etc.
Client browsers can download these resources unchanged and render them as required.
For example, when an HTML page includes an <APPLET> tag that refers to an applet in a jar file.
The web container delivers the JAR file to the client browser unchanged.
Typically, the container reads the static resources from the file system, and writes the contents directly to the
network connection. The interpretation of the contents of these resources is the responsibility of the client
browser. In order to help the browser render the file correctly, the container sends the MIME type of the file.
These MIME types can be set in the deployment descriptor of the web application.
Note: Although JSP pages are included as public resources in a web application; the container does not show
them directly to clients. The Container automatically converts JSP Page into Servlets.The Servlets is then
compiled and invoked to generate the response for the client.
However, since a JSP Page is often considered more to an HTML document than to a java class, JSP Pages are
also included under public resources.

Private Resources
Of course, there are certain resources that clients should not load directly. There may be files that the client
should not view, such as configuration files or they may be files that the container must perform some
processing on before sending the response to the client, like servlets. These private resources are stored in the
WEB-INF directory, or its subdirectories.
The Types of resources that clients should not download directly include:
• Servlets – These components include application logic, and possibly access to other resources such as
database. Any other file in the web application that servlets access directly.
• Resources that are meant for execution or use on the server side, such as java class file and JAR files
for classes used by your servlets.
• Temporary files created by your applications.
• Deployment descriptors and other configuration files.
These resources are private and as such are accessible only to their own web application and the container. In
order to accommodate private resources the web container requires the WEB-INF directory to be present in
your application. It your web application does not contain this directory it will not work.
The WEB-INF directories includes:
• A web.xml file. This is the deployment descriptor.
• A Subdirectory named classes. This directory is used to store server-side Java class files such as
servlets and other helper classes, structured according to the usual Java packaging rules.
• A lib subdirectory to contain JAR files used by the web application.

Advantage of the Structure
• Each application exists in a ‘sand-box’. The public and private resources of an application are
independent of any other application that the container may be running.
• When a new application is added to the J2EE server, we can simply add the appropriate context root
in the deploy tool of the reference implementation, without disturbing any other application.
• The Container knows where to look for classes. This means that you do not need to explicitly add
these classes and JAR files to the CLASSPATH.
• The difference between a conventional web server and a web container is that each web application
has its own document root.
• Similar to the public resources, Private resources of different web applications are stored in different
folders.
• According to the Servlet specification a container should load classes/JAR files of each web
application using a different class loader. it is for this reason that servlets, JSP Pages, and other
classes that are part of one web application cannot see classes in other application and therefore
cannot share static variables or singleton classes, for Example. This is easily achieved by the
structure discussed above.
Thus, even if you deployed the same web application twice (each mapping to a different URL) as for as
container is concerned they are two entirely different applications. such applications cannot share information.
As a result, web containers create a virtual partitioning of web applications within the container.

Web Archive Files

The various directories and files that make up a web application can be packaged into a web application archive
(WAR) file. The process is similar to the packaging of java class files into JAR files. The purpose of the
packaging is the same; it is to provide a simplified way to distribute Java Class files and their related resources.
WAR files can be created using the same jar tool that is used to create JAR files. The Web application can be
deployed as a WAR file, rather than the unpackaged collection of directories and files.
Example:
jar – cf chat.war * press enter
This command packs all the contents under the current directory, including subdirectories into an
archive file called chat.war.
-c option is used for creating a new archive.
-f option to specify the target archive file name.
It the verbose option is specified using –v , the names of the files and directories included in the archive will be
output to the screen.
You can use the following command to view the contents of a WAR file:
jar - tvf chat.war
Note:- Instead of including all the contents, you may select individual files and subdirectories while creating
WAR files. You can also used a standard ZIP file manipulation tool such as WinZip to create and manipulate
WAR files. Note that jar-tool automatically create the META-INF sub-directory and its contents.

Deploying a WAR File
Any Servlet 2.2 or higher compliant server will automatically deploy an application packaged as a WAR file, as
long as the location of a WAR file is explicitly stated.

When Shared WAR files be used
• Should not be used during developers.
• During development try to use auto reload feature for java classes.
Mapping Request to Applications
In a Web Container each web application is associated with a context and all resources in a web application
exist relative to that context.
Note: - The following Entry should be preset in the server.xml file. The server.xml file is stored in the
following path
                C:Tomcat 5.0confserver.xml
You can write the following code in server.xml before </Host> tag in server.xml.



Tomcat Web Server
Folders w.r.t Catalina-home
1. bin - executable ( startup, shutdown, catalina.bat)
2. common – jar files visible to web applications as well as internal tomcat code.
3. conf – server level configuration.
    • catalina policy – security polices , catalina policy
    • server.xml – for configuration tomcat server
    Ex: <HostName--------> element and
    <Context------------>element
    • web.xml – contains default configuration for all the web applications. Application
    specific resources should not be configured here.
    Example: <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    </welcome-file-list>
Note: - Could be overwritten by a web application by specifying different welcome file list in the application web.xml.
4. logos
5. server – server web applications , admin(server administration), manager(deployment)
6. shared – classes visible to all the web applications, but not to internal tomcat code.
7. temp – temporary files
8. webapps – user web application, example(Greeting) application.
9. work – session information, jsp compilation( sometimes the classes have to be deleted manually).

Web Application: Development to Deployment with Example

Example: 1. Greeting Application (index.html, web.xml, GreetingServlet.java)





Directory Structure for web Application Greeting

 


Steps from Development to deployment:
Step: 1 Create the following structure in your application folder (say D:application   )

 

 Step: 2 Write code for Greeting servlet and save copy the source in src folder (GreetingServlet.java).
Step: 3 Write code for welcome file (index.html) and save / copy it into folder web.
Step: 4 compile the java files so that the package hierarchy is created in the WEB-INF/classes folder.
            javac –d D:applicationservletswebWEB-INFclassesGreetingServlet.java
            Note: - while compiling, make sure that either jsdk.jar or j2ee.jar or servlet-api.jar is in the
Classpath. (C:j2sdklibj2ee.jar on PU server).
Step: 5 Create folders servlets in the webapps folder (C:Tomcat 5.0webapps)
Step: 6 Copy the contents of the web folder (d:applicationservletsweb) into the folder servlets created in
            Step5.
Step: 7 Stop and Restart the tomcat server to refresh the web application.




Accessing Greeting Application
Step: 1 http://localhost:8080/servlets or http://localhost:8080/servlets/index.html
            The following will be displayed in the browser:
Step: 2 Fill the Name and E-Mail fields.
Step: 3 Click on the submit button.
Step: 4 GreetingServlet will be invoked and will give the following response.

Directly Accessing The GreetingServlet
            Type the following URL in the address bar: http://localhost:8080/servlet/servlets/org.test.GreetingServlet
            And observe the response.
            Note – uncomment InvokerServlet and it’s mapping from tomcat/conf/web.xml
            (Response will indicate that GET method is not support.)

Accessing Using GET method for index.html
Step: 1 Modify the index.html file:
            Change method = “POST” to method = “GET”
Step: 2 Access index.html file.
Step: 3 Click on Submit button after filling name and email.
Step: 4 observe the response (Response will indicate that GET method is not supported).

Accessing GreetingServlet after adding doGet( ) method
Step: 1 Add doGet( ) method in the GreetingServlet.Simply copy the code of doPost( ) method without
            any change.
Step: 2 Recompile the GreetingServlet.java
Step: 3 Copy the class file into folder C:Tomcat 5.0webappsservletsWEB-INFclasses
Step: 4 Stop and Restart the greeting Application in tomcat web server.
Step: 5 Access the GreetingServlet directly and through index.html file and observe the response. (The
            Servlet response will be displayed in both the cases.)

Deploying Using .war file
Step: 1 to Step: 5 will remain same.
Step: 6 move to web (D:applicationservletsweb) folder and give the following command:
            jar -cf servlets.war *
            See that the file greeting.war is created in the web folder.
Step: 7 Copy servlets.war file into webapps folder of tomcat. Tomcat supports not deployment (which
            Is on by default) so the war will be extracted and web application “servlets” will be deployed.
            Confirm this by checking that the folder “servlets” is created and by verifying the content of
            This folder. Or Access tomcat manager through the URL: http://localhost:8080/manager/html
            and then deploy war file.