Advanced Java Programming Umar Kalim Dept. of Communication Systems Engineering umar.kalim@niit.edu.pk http://www.niit.edu.pk/~umarkalim 26/10/2007 Fall 2007 cs420

Agenda Web application, components and Web container Technologies used in Web application Web application development and deployment steps Web Application Archive (*.WAR file) *.WAR directory structure WEB-INF subdirectory Configuring Web application Web application deployment descriptor (web.xml file) Reference http://www.javapassion.com/j2ee Presentation by Sang Shin So this is the list of topics we are going to talk about in this session. First, we will define a few terms: “web application”, “web components” and “web container”. Next, we will talk about the steps you will follow to develop and deploy a web application. Then we will talk about “Web Application Archive”, which is called WAR file in short. We will look into the directory structure of a WAR file especially a meta sub-directory called WEB-INF. A Web application has a accompanying configuration file called web.xml. This file is referred to as the deployment descriptor of the web application and contains all the configuration information of the application that web container needs to know in order to deploy and run the application properly. Understanding the web.xml file is important since you are going to have to construct web.xml file as part of development of your web application. Then we will go through some life-cycle operations that you can perform over your web applications, for example, installing and deploying, listing all web applications that are currently running on the target web container and updating, removing, undeploying them.

Web Application, Components and Container So let's understand a few terms.

Web Components & Container Applet Container Web Container EJB Container Applet HTTP/ HTTPS JSP Servlet RMI EJB J2SE JavaMail JavaMail JNDI JMS JTA RMI/IIOP JDBC JNDI JMS JTA RMI/IIOP JDBC App Client Container JAF JAF App Client HTTP/ HTTPS J2SE RMI JNDI I talked about the container and component model of J2EE architecture during the J2EE overview session. Under component and container architecture of J2EE, the business logic (typically as EJB's), contents or presentations (typically as web-tier components such as Servlet and JSP components) are captured in the form of components and those components are then run within corresponding host execution environment called containers. (I am using the term “components” a bit loosely here for Servlet and JSP since they are not really components in a strict sense.)‏ In the web-tier container, the components are constructed in the form of web components and web components can be either in the form of servlet or JSP pages while in the EJB-tier container, the components are constructed in the form of EJB beans. JMS RMI/IIOP JDBC J2SE J2SE Database

Web Components & Container Web components are in the form of either Servlet or JSP (along with JavaBean's and custom tags) Web components run in a Web container Tomcat and Resin are popular web containers All J2EE compliant app servers (Sun Java System App Server) provide web containers Web container provides system services to Web components Request dispatching, security, and life cycle management So just to repeat what I just said, web components are in the form of either servlet or JSP pages. And web components run in a web container. And there are a few popular web containers out there, for example, Tomcat and Resin are two most popular web containers. I said that containers provide host execution environment for the components providing some system services. For web components, the web container provides several system services, for example, receiving service requests from clients and then dispatching them to appropriate web components, and life cycle management of your components. For example, the web container can figure out when it is the time to create an instance of servlet class to handle the incoming service request and when to remove the instance.

Web Application & Components Web Application is a deployable package Web components (Servlets and JSP's) Static resource files such as images Helper classes Libraries Deployment descriptor (web.xml file) Web Application can be represented as A hierarchy of directories and files (unpacked form) or *.WAR file reflecting the same hierarchy (packed form) OK. We have talked a bit on what a web component is, and how web components run in a web container. Now let's talk about a web application. A web application is basically a collection of everything that constitutes a deployable package. The deployable package contains multiple web components, that is, multiple servlets and JSP pages, and static resource files such as images that are part of displayable HTML pages, helper classes that are used by the web components, and library classes and finally deployment descriptor (web.xml file). A Web application is defined as a hierarchy of directories and files in a standard layout as specified in Servlet specification. Such a hierarchy can be accessed in its unpacked form, where each directory and file exists in the file system separately, or in a packed form known as a Web Application Archive, or WAR file. The former format is more useful during development, while the latter is used when you distribute your application to the target platform.

Technologies used in Web Applications .

Web Request Handling In the Java 2 platform, web components provide the dynamic extension capabilities for a web server. Web components are either Java servlets, JSP pages, or web service endpoints. The interaction between a web client and a web application is illustrated in the figure of the slide. The client sends an HTTP request to the web server. A web server that implements Java Servlet and JavaServer Pages technology converts the request into an HTTPServletRequest object. This object is delivered to a web component, which can interact with JavaBeans components or a database to generate dynamic content. The web component can then generate an HTTPServletResponse or it can pass the request to another web component. Eventually a web component generates a HTTPServletResponse object. The web server converts this object to an HTTP response and returns it to the client.

Java Web Application Technologies Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. Although servlets and JSP pages can be used interchangeably, each has its own strengths. Servlets are best suited for service-oriented applications (web service endpoints are implemented as servlets) and the control functions of a presentation-oriented application, such as dispatching requests and handling nontextual data. JSP pages are more appropriate for generating text-based markup such as HTML, Scalable Vector Graphics (SVG), Wireless Markup Language (WML), and XML. Since the introduction of Java Servlet and JSP technology, additional Java technologies and frameworks for building interactive web applications have been developed. These technologies and their relationships are illustrated in the figure.

Web Application Development and Deployment Steps (using hello2 example under J2EE 1.4 tutorial)‏ Now let's go over the steps needed for the development and deployment of a web application.

Web Application Development and Deployment Steps Write (and compile) the Web component code (Servlet or JSP) and helper classes referenced by the web component code Create any static resources (for example, images or HTML pages) Create deployment descriptor (web.xml) Build the Web application (*.war file or deployment-ready directory) Deploy the web application into a Web container Web clients are now ready to access them via URN So this is the list of steps you will follow in order to develop and deploy a web application. First, you will write and compile the web component code. Web component code is either servlet Java code or JSP pages and helper classes that are used by the web components. You also need to create any static resources such as images or HTML pages. Next, you will create deployment descriptor, that is, the web.xml file. Then you will build web application. As was mentioned, a web application can be either in the form of *.war file (packed form) or laid-out form of *.war file (unpacked form) as was discussed in previous slide. A *.war file will be a compressed file with the same layout as the build directory. Then you will deploy the web application to the web container. We will discuss the difference between “installation” and “deployment” later on. (There is a fine distinction between the two.) Once a web application is deployed, then client can access the web components through the HTML browser. So let's go over each of these steps one by one.

1. Write and compile the Web component code Create development tree structure Write either servlet code or JSP pages along with related helper code Create build.xml for Ant-based build (and other application development life-cycle management) process IDE (i.e. NetBeans) handles all these chores So the first step is to write and compile web component code. Now just like any other application development, you might want to create development directory structure that fits your need. As we will see in the following slide, people have recommended directory structure they found suitable for web application development. (This is only a recommendation, of course.)‏ Once you create an appropriate development directory structure, you can then write servlet or JSP along with related helper classes and other pieces. Now another thing people find quite useful is to use ANT build tool for the development and deployment tasks of web applications. As we will see later on, ANT is basically platform independent make utility. And the file that contains the build instructions that ANT uses is called build.xml file.

Development Tree Structure Keep Web application source separate from compiled files facilitate iterative development Root directory (example from hello2 sample code from J2EE 1.4 tutorial)‏ build.xml: Ant build file src: Java source of servlets and JavaBeans components web: JSP pages and HTML pages, images To order to facilitate iterative development/deployment and also in order to keep source code separate from compiled files, the source code for the tutorial examples is stored in the following structure under each application directory, for example, for hello1 web application: build.xml - Ant build file context.xml - Optional application configuration file src - Java source of servlets and JavaBeans components web - JSP pages and HTML pages, images The Ant build files (build.xml) distributed with the examples contain *targets for creating an unpacked WAR structure in the build subdirectory of the hello1 application *targets for copying and compiling files from the src directory to the build directory *targets for invoking the web container's manager commands to install, reload, remove, deploy, and undeploy applications.

Example: hello2 Tree Structure (before “ant build” command) src/servlets GreetingServlet.java ResponseServlet.java web WEB-INF web.xml duke.waving.gif build.xml So this is an example directory structure of hello1 web application you find in the Java WSDP. There are two servlet Java source files. And there is a web directory called web which contains WEB-INF directory and other static resource files. You will code each web component in the src directory.

2. Create any static resources HTML pages Custom pages Login pages Error pages Image files that are used by HTML pages or JSP pages Example: duke.waving.gif The next step is to create any static resources that will be used by the web components. And they include some static HTML pages or image files that are used by the HTML pages or JSP pages. And an example of image is duke that you see quite often in various Java-related web pages. Static resources such as image file are stored in the application's web directory.

3. Create deployment descriptor (web.xml) Deployment descriptor contains deployment time runtime instructions to the Web container URL that the client uses to access the web component Every web application has to have it The next step is to create deployment descriptor, web.xml file. By the way, the name of this file has to be web.xml file. Now web.xml file contains deployment time and runtime instructions to the web container. For example, you can specify the URN that clients of your web applications will use to access your web components. (We will talk about this URN later on in detail.) Every web application has to have a web.xml file. The web.xml file is coded and stored in the application's web\WEB-INF directory.

4. Build the Web application Either *.WAR file or unpacked form of *.WAR file Build process is made of create build directory (if it is not present) and its subdirectories compile Java code into build/WEB-INF/classes directory Java classes reside under ./WEB-INF/classes directory copy web.xml file into build/WEB-INF directory copy image files into build directory Once you have all the pieces, you can create a web application. As mentioned before, a web application is basically a deployable package that contains everything that is needed for the deployment. As mentioned before, a web application is either in the form or *.war file (packed) or laid out form of the war file (unpacked). Typically a build process for the web application involves creating “build” directory which functions as the root directory for the compile time generated pieces such as java classes and pieces that are needed to create *.war file such as web.xml file. For example, the compiled Java classes will end up residing in “build/WEB-INF/classes” directory and web.xml will be copied into “build/WEB-INF” directory and the image files will be copied into the “build” directory itself. Basically the “build” directory is the reflection of directory structure that a particular web container expects (in unpacked form).

Example: hello2 Tree Structure (after “asant build” command)‏ src web build.xml build WEB-INF classes GreetingServlet.class ResponseServlet.class web.xml duke.waving.gif So this is an example of hello1 web application. Once the build process is completed via “ant build” command, “build” directory gets created if it is not present before, and GreetingServlet.class and ResponseServlet.class class files are put into “classes” subdirectory of WEB-INF directory and web.xml file is copied from “web” directory to “build/WEB-INF” directory and image file is copied from “web” directory into “build” directory. Now the build directory is now ready to be taken either as a source directory for creating *.war file (packed form) or can be copied over to web container (unpacked form) for deployment.

5. Deploy Web application Deploy the application over deployment platform such as Sun Java System App Server or Tomcat 3 ways to deploy to Sun Java System App server asadmin deploy --port 4848 --host localhost –passwordfile "c:\j2eetutorial14\examples\common\admin-password.txt" --user admin hello2.war (asant deploy-war)‏ App server admin console NetBeans Once you built a ready-to-deployable web application, you can now deploy the application over the web container.

6. Perform Client Access to Web Application From a browser, go to URN of the Web application Once your web application has been deployed, then a client (typically a browser) can try to access the web resources by specifying the appropriate URN address.

http://localhost:8080/hello1/greeting So for the hello1 example web application, a client will specify http://localhost:8080/hello1/greeting to access the hello1 web resource.

Running Web Application This is response html page that gets displayed as a result of the web resource handling of the first HTTP request that comes from the client.

Web Application Archive OK, now let's talk about WAR file.

Web Application Web application can be deployed in two different forms a *.war file or an unpacked directory laid out in the same format as a *.war file (build directory)‏ Use *.war file when you have to deploy on a remote machine asant deploy-war command As was mentioned a couple of times already, a web application can be installed or deployed in two different forms, either as a *.war file (packed form) or unpacked directory that reflects the same directory structure of the *.war file. Now when you “install”, you can use either form while when you do “deploy” you can use only *.war file. And I will explain why this is the case later on.

What is *.WAR file? Ready to deploy'able package over web container Similar to *.jar file Contains things to be deployed Web components (servlets or JSP's)‏ Server-side utility classes Static Web presentation content (HTML, image, etc)‏ Client-side classes (applets and utility classes)‏ Reflects contents in build directory So what is war file? It is a ready-to-deployable package over web container. It is like *.jar file and obviously contains things that need to be deployed over the container such as web service components (servlets, JSP pages), server side helper or utility classes, static resources, and sometimes applet classes that would be needed by the client. As was mentioned before, it reflects the contents of the “build” directory we talked about.

Document Root & Context Document Root of the Web application Top-level directory of WAR Contains JSP pages, client-side classes and archives, and static Web resources are stored Also contains WEB-INF directory A context is a name that gets mapped to the document root of a Web application /hello1 is context for hello1 example Distinguishes a Web application in a single Web container Has to be specified as part of client URN Now let's talk about *.war file's directory structure a bit. The top level directory of the war file is called “document root” of the web application. And the “document root” directory contains JSP pages, client side classes and archive file such as applet code and static web resources. The document root also contains WEB-INF directory. Now one terminology you have heard many times (but maybe were not sure what it exactly is) is what is called “web application context” or “context” in short. Basically the context is the name of the document root of your web application. For example, /hello1 is the context name of hello1 example. Context is a way to distinguish various web applications in a single web container. The context has to be specified as part of “request path” that is specified by the client. (We will talk about “request path” later on in this presentation.)‏

Directory Structure of *.WAR file This picture shows the directory structure of *.war file. Please note that the “WebApplicationName” directory reflects the Document root, thus the context.

Directory Structure of *.WAR file

How to Create *.WAR file? 3 different ways Use IDE (NetBeans) Use ant tool after putting proper build instruction in build.xml file “asant create-war” (under J2EE 1.4 tutorial)‏ Use “jar cvf <filename>.war .” command under build directory So how do you create a *.war file? There are 3 different ways to create *.war file. If you are using an IDE, creating and deploying *.war file gets handled via one or two clicks. For J2EE 1.4 tutorial sample applications, you can use “asant create-war” command with proper build scripts. Or you can use “jar” command to create the war file. Jar command in this case is like zip utility.

Example: Creating hello2.war via “asant create-war” command C:\j2eetutorial14\examples\web\hello2>asant create-war Buildfile: build.xml ... create-war: [echo] Creating the WAR.... [delete] Deleting: C:\j2eetutorial14\examples\web\hello2\assemble\war\hello2.war [delete] Deleting directory C:\j2eetutorial14\examples\web\hello2\assemble\war\WEB-INF [copy] Copying 1 file to C:\j2eetutorial14\examples\web\hello2\assemble\war\WEB-INF [copy] Copying 2 files to C:\j2eetutorial14\examples\web\hello2\assemble\war\WEB-INF\classes [war] Building war: C:\j2eetutorial14\examples\web\hello2\assemble\war\hello2.war [copy] Copying 1 file to C:\j2eetutorial14\examples\web\hello2

Example: Creating hello2.war via jar command C:\j2eetutorial14\examples\web\hello2\build>jar cvf hello2.war . added manifest adding: duke.waving.gif(in = 1305) (out= 1295)(deflated 0%)‏ adding: servlets/(in = 0) (out= 0)(stored 0%)‏ adding: servlets/GreetingServlet.class(in = 1680) (out= 887)(deflated 47%)‏ adding: servlets/ResponseServlet.class(in = 1090) (out= 572)(deflated 47%)‏ C:\j2eetutorial14\examples\web\hello2\build>jar xvf hello2.war created: META-INF/ extracted: META-INF/MANIFEST.MF extracted: duke.waving.gif created: servlets/ extracted: servlets/GreetingServlet.class extracted: servlets/ResponseServlet.class So in this example, I am creating hello2.war file using “jar” command. Basically you “cd” to “build” directory and then use “jar” command to pick up all the pieces underneath it into the “hello2.war” file. Please don't forget the dot(.) at the end in this example. In the lower part of the slide, I use “jar tvf” command just to show the contents of the newly created *.war file.

WEB-INF Directory Subdirectory of Document root Contains web.xml : Web application deployment descriptor JSP tag library descriptor files Classes : A directory that contains server-side classes: servlets, utility classes, and JavaBeans components lib : A directory that contains JAR archives of libraries (tag libraries and any utility libraries called by server-side classes) Now what is this WEB-INF directory? WEB-INF directory contains web.xml file, JSP tag library descriptor files (we have not learned this yet so don't worry about it if you don't understand), and “classes” directory that contains servlet classes and “lib” directory that contains various jar files that could contain Java classes that are used by the web components and their helper classes.

HTTP request URL & Web component URN (alias) & Context Request URL: User specified access point of a web resource http://[host]:[port]/[request path]?[query string] [request path] is made of context and web component's URN http://localhost:8080/hello1/greeting?username=Monica Context: Name of the root document of a web application – Identifies a particular application on that server /hello1 is context Now I would like to talk about how a client can access the web service and explain some related terms. First “request URL” is user specified access point of a web resource. This is something that is being passed to the web components as part of HTTP request. The typical request URL is made of http://[host]:[port]/[request path]?[query string] The [request path] is made of “context” of the web application and the “URN of the web component”. For example, in the case hello1 example, “/hello1” is context and “/greeting” is the URN of the web component. So the [request path] will look like “/hello1/greeting”. Now as mentioned before, context is the name of the root document of the web application. And as a web application developer/deployer, you can choose any name as context name for your application. The context name is specified in the web.xml deployment descriptor.

Configuring Web Application via web.xml Now let's talk about how to configure your web application using web.xml deployment descriptor.

Configuring Web Application Configuration information is specified in web.xml (Web Applications Deployment Descriptor) Web applications are configured via elements contained in Web application deployment descriptor (web.xml file). You can either manually create web.xml using a text editor of your choice or use a tool. So let's go over some configuration elements that can be specified in web.xml file.

Web Applications Deployment Descriptor (web.xml) Prolog Alias Paths Context and Initialization Parameters Event Listeners Filter Mappings Error Mappings Reference to Environment Entries, Resource environment entries, or Resources So this is the list of things that can constitute web.xml file. The most important configuration information that you need to understand is what is called alias paths, which define which URL is mapped to which web components.

Web Applications Deployment Descriptor (web.xml) Case sensitive Order sensitive (in the following order) icon, display-name, description, distributable context-param, filter, filter-mapping listener, servet, servlet-mapping, session-config mime-mapping, welcome-file-list error-page, taglib, resource-env-ref, resource-ref security-constraint, login-config, security-role env-entry, ejb-ref, ejb-local-ref Not only elements in web.xml are case sensitive, they are also order-sensitive. In other words, the elements in web.xml file has to be defined in a specific order that is specified in the Servlet specification. This slide shows the ordered list of configuration elements if they are present in the web.xml (many of them are optional).

Prolog (of web.xml) Every XML document needs a prolog <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> Since the deployment descriptor is an XML document, it requires a prolog. The prolog of the web.xml file is as follows: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

Alias Paths (of web.xml) When a request is received by Servlet container, it must determine which Web component in a which web application should handle the request. It does so by mapping the URL path contained in the request to a Web component A URL path contains the context root and alias path http://<host>:8080/context_root/alias_path Alias Path can be in the form of either /alias-string (for servlet) or /*.jsp (for JSP)‏ When a request is received by Tomcat it must determine which Web component should handle the request. It does so by mapping the URL path contained in the request to a Web component. A URL path contains the context root and an alias path http://<host>:8080/context_root/alias_path Before a servlet can be accessed, the Web container must have least one alias path for the component. The alias path must start with a / and end with a string or a wild card expression with an extension (*.jsp, for example). Since Web containers automatically map an alias path that ends with *.jsp, you do not have to specify an alias path for a JSP page unless you wish to refer to the page by a name other than its file name.

Alias Paths (of web.xml) <servlet> <servlet-name>greeting</servlet-name> <display-name>greeting</display-name> <description>no description</description> <servlet-class>GreetingServlet</servlet-class> </servlet> <servlet-name>response</servlet-name> <display-name>response</display-name> <servlet-class>ResponseServlet</servlet-class> <servlet-mapping> <url-pattern>/greeting</url-pattern> </servlet-mapping> <url-pattern>/response</url-pattern> So in order to set up mappings of Hello application in the Web deployment descriptor, you must add “servlet” and “servlet-mapping” elements to the web.xml file. (By the way, to define an alias for a JSP page instead of a servlet, you must replace the servlet-class subelement with a jsp-file subelement in the servlet element.)‏

Error Mappings (of web.xml)‏ Maps status code returned in an HTTP response to a Java programming language exception returned by any Web component and a Web resource <error-page> <exception-type>exception.OrderException</exception-type> <location>/errorpage.html</location> </error-page> Error mapping information is also specified in the deployment descriptor. That is, an application exception can be mapped into a custom error page. Or an HTTP response can be mapped to a Java exception, like in the example above. Otherwise, a default error page will be displayed.

References (of web.xml) Need when web components make references to environment entries, resource environment entries, or resources such as databases Example: declare a reference to the data source <resource-ref> <res-ref-name>jdbc/BookDB</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> Now references. When web components make references to environment entries or resource environment entries, or resources such as databases, you can also specify information on those in the deployment descriptor. And in this example, a declaration to the data source is specified.

Example web.xml of hello2 <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" version="2.4" 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"> <display-name>hello2</display-name> <servlet> <display-name>GreetingServlet</display-name> <servlet-name>GreetingServlet</servlet-name> <servlet-class>servlets.GreetingServlet</servlet-class> </servlet> <display-name>ResponseServlet</display-name> <servlet-name>ResponseServlet</servlet-name> <servlet-class>servlets.ResponseServlet</servlet-class> <servlet-mapping> <url-pattern>/greeting</url-pattern> </servlet-mapping> <url-pattern>/response</url-pattern> </web-app> So this is the complete web,xml file of the hello1 web application. Given that hello1 is rather simple web application, the only thing its deployment descriptor specifies is servlet and its mapping to URNs. For example, the part in the blue color specifies information about the servlet such as name and servlet classes and the part in the red color specify the mapping between servlet and their URNs. These URNs are the ones that clients use when they access the web components. And when the web container receives the URN from a client, it knows which servlet classes to invoke by looking at the deployment descriptor's servlet mapping elements. Other elements of the deployment descriptor and how they are used are referenced in future classes.

Summary & Questions? That’s all for today! Fall 2007 cs420