What J2EE Architecture

codenotes for j2ee ejb jdbc jsp and servlets pdf, what are different j2ee technologies, what is j2ee connector architecture, what j2ee design patterns in used in a servlet pdf free download
Dr.DouglasPatton Profile Pic
Dr.DouglasPatton,United States,Teacher
Published Date:26-07-2017
Your Website URL(Optional)
for J2EE EJB, JDBC, JSP, and Servlets Edited by Gregory Brill The developer’s shortcut. Start here. Chapter 1 INTRODUCTION ORIENTATION, HISTORY, BACKGROUND What Is the Java 2 Enterprise Edition (J2EE)? Depending upon whom you ask, Java 2 Enterprise Edition (J2EE) is one of many things. A systems architect might tell you that J2EE is a plat- form and design philosophy for large enterprise systems. Your local server administrator might tell you that J2EE is a combination of vendor products, WAR, JAR, and EAR files. A developer might tell you that J2EE is marketing spin wrapping up a suite of toolkits. In fact, J2EE comprises three major components. 1. A conceptual definition for enterprise systems architecture. This definition provides a rigorous design philosophy for build- ing large, scalable, web-enabled systems. 2. A collection of API extensions that relate to enterprise systems. These APIs range from e-mail access to database connectivity, bridging concepts as different as distributed computing and web-based applications. 3. A new deployment specification for packaging Java compo- nents into a single enterprise solution. Basic Java uses a simple “Java Archive” standard for packaging a set of common class objects into a single deployable file. J2EE extends this concept to Web Archive (WAR) and Enterprise Archive (EAR) formats® . 4 CodeNotes for J2EE for deploying larger enterprise systems. This deployment speci- fication includes support for role-based security. History In 1999, Sun announced a fundamental redefinition of the Java platform. Java had originally been designed as an all-encompassing “Write Once, Run Anywhere™” system; but Java applications rapidly exploded across a tremendous range of platforms, from smart cards to air condi- tioners (e.g., www.myappliance.com) to distributed, mission-critical en- terprise systems. Obviously, the requirements for an offline payment system on a smart card are vastly different from those of an enter- prisewide, web-enabled stock trading platform. Sun initially supported the different platforms by providing a core SDK and an assortment of extension APIs. This approach rapidly be- came unwieldy, and Sun redefined the Java platform into three distinct versions: Java 2 Micro Edition (for embedded applications such as smart cards), Java 2 Standard Edition (for normal Java applications), and Java 2 Enterprise Edition (for large-scale, distributed, web-enabled applica- tions). The J2EE APIs When the initial J2EE specification was announced, many of the enter- prise APIs already existed as independent packages. Thus it is often difficult to tell whether an API is part of Java 2 Enterprise Edition or Java 2 Standard Edition, or is a stand-alone package, or is included in more than one edition. As the various Java editions mature and the lit- erature catches up with the changes in the Java platform, these distinc- tions should become clearer. The most important J2EE 1.2.1 components are: • JDBC 2.0—JDBC is the primary mechanism for using Java to communicate with SQL-compliant databases. J2EE requires the JDBC 2.0 Optional Package, an extension to the core JDBC API included with the Java 2 Standard Edition. Chapter 3 explains the core concepts of JDBC and working with relational databases. • Java Servlets 2.2—Servlets are server-side web programs that are primarily gateways between web interfaces and middle-tier components. Servlet technology is an essential component to building secure, scalable web-enabled systems. Chapter 5 covers fundamental Servlet concepts and provides the framework for JavaServer Pages.. Introduction 5 • JavaServer Pages (JSP) 1.1—JavaServer Pages (Chapter 6) ex- tend the power of Servlets by providing a simple mechanism for decoupling web content generation from application and business logic. • Java Naming and Directory Interface (JNDI) 1.2—JNDI pro- vides a transparent Java interface to various naming and direc- tory services, including LDAP, NDS, DNS, and NIS(YP). JNDI is briefly covered (along with RMI and JavaMail, below) in Chapter 4, and extensively covered on the CodeNotes website. • Remote Method Invocation (RMI)—J2EE supports distributed computing by providing interfaces for both CORBA and a pro- prietary Remote Method Invocation system. RMI can crosscom- municate with CORBA using the Internet Inter-ORB Operating Protocol (IIOP). • JavaMail 1.1—The JavaMail API provides an interface for send- ing and receiving e-mail through standard systems such as SMTP and POP3. This CodeNote describes sending e-mail, and several examples for reading e-mail are available on the website a J2010004. • Enterprise JavaBeans (EJB) 1.1—A JavaBean is a small Java class that follows design rules for exposing member variables. Enterprise JavaBeans (Chapter 6) extend the JavaBean concept into the world of distributed computing. EJBs are used for en- capsulating business logic in small, reusable packages that are easily configured into complex applications. • Java Transaction API (JTA) 1.0—This component provides sup- port for distributed transaction systems. The JTA provides a user- level interface for creating and managing transactions. The use of JTA is beyond the scope of this CodeNote, but several exam- a ples are available on the WebSite J2010001. • Java Messaging Service (JMS) 1.0—Many enterprise systems rely on secure, reliable messaging systems for publish-subscribe and broadcast services. JMS provides an interface to these tech- nologies. J2EE 1.2.1 requires that the API definitions be included with any J2EE-compliant server product, but does not require an actual implementation. Although JMS is not covered in this book, several articles on JMS can be found on the website a J2010002. Several additional components, such as the Java Authentication and Au- thorization Service (JAAS), are in draft form and will be included in the next J2EE release, version 1.3, which was in its final draft phase at the® . 6 CodeNotes for J2EE time of writing. Chapter 9 (Darkside) includes a brief discussion of sev- eral of these technologies. Deployment Specification A common belief is that J2EE is nothing more than a wrapper for a set of toolkits. However, J2EE does contain some new tools that are inher- ently part of the specification. These tools provide packaging for sys- tems components. By extending the traditional Java Archive, or JAR file, into Web Archive (WAR) and Enterprise Archive (EAR) files, the J2EE deployment specification provides much greater flexibility for dis- tributed enterprise systems. In addition to packaging, the deployment specification also includes definitions for role-based security. Role-based security can define access to individual methods on EJBs and access to individual web pages in a WAR. These security settings can also be accessed programmatically in- side EJBs, Servlets, and JSPs for finer-grained control. Finally, the deployment specification includes support for environ- ment variables maintained by the J2EE container. These variables can range from database access to e-mail connectivity to default parame- ters. Environment settings are accessible through a naming service and JNDI. The deployment specification is detailed in Chapter 8 (Packaging and Deployment). ABOUT THE VENDOR Sun Microsystems Sun (www.sun.com) originally developed Java as a language for televi- sion “set top boxes,” which were an instrumental component of the an- ticipated interactive TV explosion. Instead, the Internet and World Wide Web exploded and Java was quickly drawn into the realm of platform in- dependent computing. Sun’s philosophy for Java consists of two key statements: “The Net- work is the Computer”™ and “Write Once, Run Anywhere”™. These two concepts are built into every aspect of Java and J2EE. Vendors JDBC, JSP, Servlets, and EJB all require components that are built by third-party vendors. These components must conform to the basic J2EE specification but can have dramatically different support for the ex- tended features of J2EE. The following lists of vendors include many of the market leaders but are by no means exhaustive.. Introduction 7 JDBC Drivers Most database vendors provide a JDBC driver for their database. For example, if you are using an Oracle database, you should strongly consider using the Oracle JDBC driver. However, several companies provide cross-database-compliant drivers that are very feature-rich. • Merant (www.merant.com) is a major player in JDBC driver de- velopment and has offerings for all of the major databases. • Inet Software (www.inetsoftware.de) provides crossplatform JDBC drivers, including an SQL Server driver. If you are in doubt when selecting a JDBC driver vendor, the best start- ing point is always Sun’s JDBC driver database (industry.java.sun.com/ products/jdbc/drivers). Service Provider Interfaces The Java Naming and Directory Interface uses Service Provider Interfaces to communicate with proprietary naming and directory ser- vices. Sun maintains a database of SPIs and vendors at: java.sun.com/ products/jndi/serviceproviders.html. Application Servers The J2EE application server market is rapidly expanding and highly competitive. The market leaders are described below, and additional a vendors can be found on the website J2010003. • BEA Weblogic (www.bea.com) is the current market leader for Java application servers. • IBM WebSphere (www4.ibm.com/software/webservers/app serv/) is another very popular Java application server. • iPlanet Application Server (http://www.iplanet.com/products/ iplanet_application/) is the J2EE offering from the Sun- Netscape alliance. • Borland AppServer (www.borland.com/appserver/) has some of the best support for EJBs and is fully J2EE compliant. Java Development Environments While you do not need a development environment for Java or J2EE, most environments offer significant advantages over text editors, includ- ing automatic code generation for JavaBeans and enhanced support for EJBs, JSPs, and other J2EE components. These environments are among the most popular:® . 8 CodeNotes for J2EE • Borland JBuilder 4 Enterprise (www.borland.com/jbuilder/) • Sun’s Forte for Java (www.sun.com/forte/) • IBM’s VisualAge for Java (www-4.ibm.com/software/ad/ vajava/) • WebGain VisualCafe (www.webgain.com/products/visual_ cafe/) You can always develop Java code in a simple text editor such as Win- dows Notepad or Unix vi. However, many text editors have advanced features such as keyword coloring and parenthesis tracking: • Emacs with the jde (jde.sunsite.dk/) • SlickEdit (www.slickedit.com) • Jext (www.jext.org/) • Jpadpro (www.modelworks.com/) NOMENCLATURE AND TERMINOLOGY The J2EE architecture is based on four key concepts: components, archives, containers, and connectors. These concepts are used through- out J2EE. Figure 1.1 shows how these concepts relate graphically. Naming or Directory Service (e.g., LDAP) JNDI SPI Database (e.g., Oracle) JDBC Driver Web E-mail System Enterprise Container (e.g., SMTP Java Bean JavaMail Provider server) Client Messaging Service Application (e.g., Tibco JMS Provider Rendezvous) Other Enterprise Information System J2EE Connector (e.g., PeopleSoft) Legend Enterprise Remaining Shapes are Component Container Connector Application Enterprise Information Systems Figure 1.1 J2EE architecture. Introduction 9 Components A component is an individual Java object (class or JSP ) or an archive of related Java objects. Components are the fundamental building blocks for J2EE and come in three flavors: 1. Web components such as JSPs, Servlets, or Web Archives. 2. EJB components, which are Java Archives containing EJB code and the deployment descriptor. 3. Client applications, which are stand-alone Java executables. Archives An archive is a package of Java code that contains one or more specific descriptors and a manifest. Deployment descriptors are the heart of the J2EE packaging specification. Descriptors provide configuration infor- mation, environment settings, role-based security, and vendor-specific information. The manifest is a packing slip that is automatically gener- ated by the archive process. J2EE defines three types of archives: 1. Java Archives (JAR)—A JAR file encapsulates one or more Java classes, a manifest, and a descriptor. JAR files are the lowest level of archive. JAR files are used in J2EE for packaging EJBs and client-side Java Applications. 2. Web Archives (WAR)—WAR files are similar to JAR files, ex- cept that they are specifically for web applications made from Servlets, JSPs, and supporting classes. 3. Enterprise Archives (EAR)—An EAR file contains all of the components that make up a particular J2EE application. Containers The container is an independent application that creates an environment for components. The container provides several key functions: 1. Life cycle management for components. The container instanti- ates new instances of a component and cleans up when the component dies. 2. Environment configuration. The container provides configura- tion information and the framework for the components. 3. Resources. The container also provides access to enterprise information systems such as databases, naming and directory services, and e-mail systems. This access is managed through connectors.® . 10 CodeNotes for J2EE Connectors The connector is where the abstract really meets the concrete. A con- nector is a translator between an enterprise information system and the J2EE interfaces. One type of connector, a JDBC driver, provides access to databases. Another type of connector, a JNDI Service Provider Inter- face, provides access to naming and directory services. The next version of J2EE is expected to standardize this area with the J2EE connector ar- chitecture.Chapter 2 INSTALLATION This chapter illustrates the process of installing J2EE and configuring Sun’s reference implementation. Throughout the book, the J2EE refer- ence implementation will be used as an example environment. If you already have a J2EE environment available, you can skip this chapter. These instructions are written for Windows platforms. The instruc- tions for most Unix systems follow the same pattern, although the down- load file and extraction programs are different. HARDWARE Sun’s recommended system requirements for Java are on the low end for working with J2EE and any of the common development environments. We recommend the following: • PC platforms: At least a Pentium II, 133 Mhz, 128 Mb RAM (256 preferred), running Windows 95/98/NT/2000/Me (NT/2000/ Me preferred) or Linux • Unix: Sun Ultrasparc (or equivalent Unix platform) with 256 Mb RAM • Macintosh: G3 with 256 Mb RAM, running OS X or Linux PPC. Configuring the reference implementation for a Macintosh in- volves several unique challenges; some pointers can be found on a the CodeNotes website J2020001.® . 12 CodeNotes for J2EE NEAT TRICKS If you are unfamiliar with working in a DOS environment inside of Win- dows, here are some useful tricks: • To start a new command window, choose Run from the start menu and type “command” (if you are using Win95/98), or “cmd” (if you are using WinNT/2000). • When you execute commands inside a Windows 95 or 98 shell, you may see error messages like “Out of environment space.” These messages can be safely ignored. Windows will automati- cally allocate more space to the process. However, if you want to prevent these error messages, simply open a Windows shell, right-click on the title bar, and select properties from the drop- down menu. Select the memory tab. In the Conventional Memory area, increase the initial environment setting to 4096. Click the Apply button and then the OK button. Close the Win- dows shell. Any new Windows shell will start with more memory. • When you need to start a process in the background, use the syn- tax “start ProgramName -options”. This will launch the process in a new command window. If you don’t preface the command with “start,” you must create a new command window (and change to the proper directory) for each process. (For Unix de- velopers, this is roughly equivalent to the syntax “ProgramName -options &”.) THE PLAN The following sections of this chapter describe the installation and con- figuration of J2EE and the components of the reference implementation. • Required installation—All J2EE applications require the J2SE Java Developers Kit, the J2EE Java Developers Kit, and configu- ration of several environment variables. • Cloudscape—Cloudscape is the database component of the Java Reference Implementation. Several of the exercises in Chapter 3 (JDBC) are illustrated with Cloudscape. • Web components—Both Servlets (Chapter 5) and JavaServer Pages (Chapter 6) require a container and an application. These chapters are illustrated with Tomcat (the container) and a basic Java web application called CodeNotes.. Installation 13 • Enterprise JavaBeans—EJBs require a significant amount of de- ployment, but no special steps are required for installation of the reference implementation. You do not need to follow all of these instructions in order to get started with J2EE. Once you have completed the Required Installation section, feel free to jump ahead to Chapter 3 (JDBC) and return to this section when or if you need to set up the additional components. REQUIRED INSTALLATION Installing the J2SE Java Developers Kit (version 1.3.1) All J2EE installations require that Java 2 Standard Edition (J2SE) be in- stalled first. J2EE exists on top of J2SE and does not contain the core Java classes or the Java Virtual Machine (JVM). If you already have JDK 1.3 installed on your machine, you can skip this section. 1. Download the J2SE Java Developer Kit from Sun (java.sun.com/ j2se/1.3/). The download file is about 30 Mb and should be called j2sdk-1_3_1-win.exe. 2. Download the JDK 1.3 documentation (java.sun.com/j2se/ 1.3/docs.html), which is about 20 Mb and called j2sdk-1_3 _1-doc.zip. 3. Launch the j2sdk-1_3_1-win.exe file. This should start an In- stallShield session. 4. After the welcome and license screens, you should have an op- tion to choose an installation directory. You can place the JDK on any drive and in any directory. You should make a note of the directory name, as it will be important later. The default path is C:\jdk1.3, and the following instructions will assume you used this directory. 5. The fourth screen allows you to choose which components to install. Only the first two entries (“Program Files” and “Native Interface Header Files”) are truly required. The “Old Native In- terface Header Files” are provided as support for older versions of Java. The Demos are useful, but not required, and the Java Sources are provided in the spirit of “open source.” 6. Continue with the installation, which should be fairly quick. 7. To install the documentation, use your favorite zip tool (e.g., WinZip) to unpack the j2sdk-1_3_1-doc.zip file. The documen- tation generally is placed in a \docs directory inside the JDK in-® . 14 CodeNotes for J2EE stall directory (e.g., C:\jdk1.3\docs), although this is not a re- quirement. This file contains the complete JavaDocs for J2SE as well as release notes, documentation for the Java tools (rmic, javadoc, javac, etc.), and links to online documentation from Sun. Installing the J2EE Software Development Kit (version 1.2.1) The J2EE SDK installation is very similar to the J2SE installation. How- ever, the J2EE SDK does not contain a Java Virtual Machine or any of the core Java functionality. If you have not already installed the J2SE JDK (v1.3), refer to the previous instructions before continuing. 1. Download the J2EE installation from java.sun.com/j2ee/ j2sdkee/. The J2EE file for Windows is j2sdkee-1_2_1-win.exe (about 10 Mb). 2. Download the documentation file from the same web page. This file is called j2sdkee-1_2_1-doc-win.exe. 3. Start the installation by running j2sdkee-1_2_1-win.exe. This should start an InstallShield program. 4. After the welcome and license screens, you should have an op- tion to choose an installation directory. You can place the J2EE SDK on any drive and in any directory. You should make a note of the directory name, as it will be important later. The default path is C:\j2sdkee1.2.1, and the following instructions will assume you used this directory. 5. Continue the installation. You don’t have any choices as to pro- gram components, so the fourth screen is irrelevant. The re- maining installation should be very quick. 6. To install the documentation, launch the j2sdkee-1_2 _1-doc-win.exe file. This will start an InstallShield session that will automatically install the documentation in the \docs subdi- rectory of your J2EE installation directory (e.g., C:\j2sdkee1.2.1\docs. Configuring the Environment Certain J2EE applications require environment variables that are de- scribed below. The various versions of Windows have different methods for configuring environment variables: • Windows 95/98—Edit the C:\autoexec.bat file. Open this file with Notepad or Wordpad. To set an environment variable, add an entry in the form:. Installation 15 SET VARIABLE=value1;value2;value3 These entries are very sensitive to extra spaces. When you have finished with your changes, save the file and restart Windows. • Windows NT4—Right-click on the “My Computer” icon, select Properties, and then select the Environment tab. • Windows 2000—Right-click on the “My Computer” icon, select Properties, select Advanced, then click the Environment Vari- ables button. • For both WinNT4 and Win2000, you have a graphical interface for adding and modifying environment variables. You also do not need to reboot after you make changes. On these platforms, add or edit the variables in the “User variables for yourname” sec- tion. Regardless of your system version, you will need to add or update sev- eral variables. If the environment variable already exists on your system, check to see if the Java entry is already present. If the entry is not pres- ent, simply add a semicolon to the end of the existing entry and then add the new entry. If the variable doesn’t exist, create it. Variable names should be fully capitalized. • CLASSPATH—The JVM uses CLASSPATH to determine where the various Java files are located. Add the j2ee.jar file (e.g.,C:\j2sdkee1.2.1\lib\j2ee.jar) and the local directory “.”. For Windows 95/98, the entry will look like: SET CLASSPATH=.;C:\j2sdkee1.2.1\lib\j2ee.jar • PATH—Many of the Java tools are stored in the bin directory of your JDK installation (e.g., C:\jdk1.3\bin). By adding this direc- tory to your path file, you will have a much easier time accessing the Java compiler (javac), Java runtime (java), and other Java tools (javadoc, rmic, etc.). SET PATH=C:\jdk1.3\bin • J2EE_HOME—Various components of the reference implemen- tation require a startup directory and base path for access to the J2EE components. This directory (e.g., C:\j2sdkee1.2.1) is called the J2EE_Home.® . 16 CodeNotes for J2EE SET J2EE_HOME=C:\j2sdkee1.2.1 • JAVA_HOME—The JAVA_HOME variable should be set to the base installation directory for your Java Developers Kit (e.g., C:\jdk1.3) SET JAVA_HOME=C:\jdk1.3 If you are working with Windows 95 or 98, don’t forget to save the autoexec.bat file and restart your computer. CLOUDSCAPE Cloudscape is a simple SQL-92 relational database that is part of the Reference Implementation. Cloudscape is automatically installed as part of the J2EE Software Development Kit. To start Cloudscape, use the command: start cloudscape –start To stop Cloudscape, use the command cloudscape –stop WEB COMPONENTS Both Chapter 5 (Servlets) and Chapter 6 (JavaServer Pages) are illus- trated with examples that use the Tomcat container and a J2EE applica- tion called CodeNotes. This section covers the installation and configuration of Tomcat as well as the building of a basic web applica- tion. JSP and Servlet Container Tomcat For demonstration purposes, this CodeNote will use the Tomcat Servlet and JSP engine, collaboratively developed by Sun and the Apache Foundation. Tomcat is available as a stand-alone package, although a modified version is included with the J2EE SDK. If you are al- ready familiar with Tomcat or have access to a different JSP/Servlet. Installation 17 container, feel free to skip ahead to the section “Creating a Web Appli- cation.” Installing the Software Tomcat is very easy to install. For the sake of brevity, these instruc- tions will demonstrate the installation of Tomcat on Windows (all versions). However, installations on other systems follow the same gen- eral steps, and specific instructions for Unix, Linux, and Solaris are available with the Tomcat download. 1. Go to jakarta.apache.org/tomcat/index.html and find the bi- nary code for the most recent Release Build. The code examples were developed against Tomcat 3.2.1, although Tomcat 4.x is in development. For Windows systems, you should download the file jakarta-tomcat-3.2.1.zip (3 Mb). If you are installing on Linux, Unix, or Solaris, you will want to download the appro- priate archive type (tar, gz, rpm, etc.). 2. Using you favorite zip tool, extract the contents of the file to your hard drive. You may put this directory anywhere you like (e.g., C:\Jakarta). You must use a command window to stop and start the server, however, so keep the path relatively short to save yourself some typing. 3. If you set JAVA_HOME in the Required Installation instruc- tions, you can skip this step. In order for Tomcat to run, you must identify your Java directory in the tomcat.bat file, which can be found in the bin subdirectory under your install directory (e.g., C:\Jakarta\bin). Edit this file and find the “Save Environ- ment Variables That May Change” section immediately after the first comments. Add a line like the following to identify your Java home directory: SET JAVA_HOME=C:\jdk1.3 This line is both case-sensitive and highly sensitive to spaces and syntax. 4. Save the tomcat.bat file. Tomcat is now installed. Running Tomcat Tomcat is a self-contained web server with support for Servlets and JSP. The default installation also includes some samples of JSPs and Servlet pages. Experimenting with these pages is a great way to test your instal- lation.® . 18 CodeNotes for J2EE 1. Open a command window or browser and find the bin directory under your Tomcat installation directory (e.g., C:\Jakarta\bin). 2. Launch the startup.bat file (or startup.sh on Unix/Linux). This should open up a new command window. The startup.bat file sets a few key environment variables and then calls tomcat.bat. 3. DO NOT close the Tomcat command window If you close the window, you will kill your Tomcat process. While this isn’t generally a problem, it is much better to use the shutdown.bat script to stop Tomcat gracefully. 4. Once Tomcat has launched, open web browser and go to http://localhost:8080/. If your computer is part of a network, you can replace “localhost” with your computer name (e.g., “Dandelion” or “www.codenotes.com”). Tomcat is set to run on port 8080 by default. Since HTTP generally runs through port 80, you must explicitly set the alter- nate port number in your URL (hence the “:8080” at the end of the example URL). 5. You should see a welcome page with some links to example pages, resources, and interest lists. Try out some of the example JSP and Servlet pages. Creating a Web Application Once you have your Tomcat server installed and running, you should create and register an application that you can use for web development. We are actually building a WAR (Web Archive) structure that is fully de- scribed in Chapter 8 (Packaging and Deployment). These instructions will get you started with a minimal application that you can use for both JSPs and Servlets. 1. Create a directory called webdev. This directory can be any- where on your system (e.g., C:\webdev). This is the root-level directory for your application. You can place all of your JSP and HTML pages in this directory or use subdirectories to organize them. The following examples will use C:\webdev as the root directory. You can name this directory whatever you want, just remember to replace C:\webdev with your directory name in the following instructions. 2. From this point on, all file and folder names are mandatory and case-sensitive. In other words, the only choice you get to make is the name of the parent directory. All other names should be entered as specified, including punctuation and capitalization. 3. Create a directory called WEB-INF inside the webdev directory. Installation 19 (e.g., C:\webdev\WEB-INF). This directory will be used for storing configuration information. 4. Inside the WEB-INF directory, create a directory called classes (C:\webdev\WEB-INF\classes) and another called lib (C:\web- dev\WEB-INF\lib). You will use these directories to store the Java code that will support your web pages. The classes direc- tory is for Servlets, JavaBeans, and other compiled Java code, while the lib directory is for JAR packages. 5. Inside the WEB-INF directory, use the tool of your choice to create an XML file called web.xml. This configuration file is used to identify the application. The contents of the file should look like this: ?xml version="1.0" encoding="ISO-8859-1"? DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd" web-app /web-app Listing 2.1 Web.xml file 6. Save and close the web.xml file. Configuring the Server Once you have built your application directory and configuration file, you must configure the server to recognize the new application. This process is similar to registering a new website with any other web server. The exact syntax and steps for configuring the server depend on the ven- dor; however, most JSP/Servlet containers support a similar configura- tion mechanism. 1. If Tomcat is currently running, use the shutdown.bat file to stop it. 2. Find the server.xml file. It should be in the Tomcat home direc- tory, under the conf subdirectory (e.g., C:\jakarta\conf\server .xml). 3. Edit the server.xml file and find the Context tag for the sample applications. It should be toward the bottom of the file in the “Special Webapps” section, and should look like this: Context path="/examples" docBase="webapps/examples"® . 20 CodeNotes for J2EE crossContext="false" debug="0" reloadable="true" /Context Listing 2.2 The Context node 4. Make sure that you select the stand-alone context rather than the one enclosed inside the virtual host example. 5. Create a new context node for your application by copying the context node from the examples application. Paste it into the server.xml file just below the examples application. 6. Change the path property. The path property is the base URL path for your application. You may choose any path you like, and it does not need to match the root folder for your applica- tion. Even though our example application is called webdev, we can set the path to “CodeNotes”: path="/CodeNotes" When you create new JSPs or Servlets and place them in the webdev directory for your application, you can access them by pointing a web browser at: http://localhost:8080/CodeNotes If your computer is connected to a network and a domain name server, you can use your actual computer name (e.g., Dande- lion) instead of localhost. Be aware that this URL is case- sensitive. 7. Change the docBase property. The docBase property tells Tomcat where your source files are located. Change the prop- erty to the directory where you have installed your application. For example, if you followed the Windows NT instructions above, the docBase directory would be docBase="C:\webdev" 8. You should also add a few parameters that tell Tomcat about your application. These parameters are fully explained in the deployment section. Add these attributes to the Context node: defaultSessionTime0ut="30" isWARExpanded="true". Installation 21 isWARValidated="false" isInvokerEnabled="true" isWorkDirPersistent="false" Listing 2.3 Context node attributes 9. The Context node for your application should now look like this, with the exception of your specific path and docBase at- tributes: Context path="/CodeNotes" docBase="C:\webdev" defaultSessionTime0ut="30" isWARExpanded="true" isWARValidated="false" isInvokerEnabled="true" isWorkDirPersistent="false" debug="0" reloadable="true" /Context Listing 2.4 The CodeNotes application descriptor 10. Save and close the file. 11. Open a new command window and change to the bin directory in your Tomcat installation directory (e.g., C:\Jakarta\bin). 12. Start Tomcat using the startup.bat file. A new command win- dow should open. 13. As Tomcat starts up, you should see a new line in the com- mand window indicating that the ContextManager has added your context. For example: 2001-05-11 12:06:00-ContextManager: Adding context Ctx(/CodeNotes) If you don’t see this message, then your installation is not properly configured. Double-check your server.xml file and make sure that the Context node is correct. Pay particular at- tention to the docBase setting. Also, make sure that your Con- text node is not in the “Virtual Server Example” section or embedded in another set of tags. 14. At this point, any JSPs or Servlets you put into your applica- tion directory (e.g., C:\webdev) will be accessible via a web browser. Copy the snoop.jsp file from the Tomcat samples

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.