From e816bdd6386b5779a59c67a1343a710ab39f7f10 Mon Sep 17 00:00:00 2001
From: remm
+ Useful references:
+Apache Tomcat @VERSION@
+
+
+
+
NOTE: The tar files in this distribution use GNU tar extensions,
+and must be untarred with a GNU compatible version of tar. The version
+of tar on Solaris and Mac OS X will not work with
+these files.
Tomcat 5.5 requires JRE 5.0 by default. Read the +RELEASE-NOTES and the RUNNING.txt file in the distribution for more details. +
+ +Packaging Details (or "What Should I Download?") +
Thank you for using Tomcat!. +
+The Apache Tomcat Project
http://tomcat.apache.org/
+
diff --git a/res/welcome.main.html b/res/welcome.main.html new file mode 100644 index 000000000..254349080 --- /dev/null +++ b/res/welcome.main.html @@ -0,0 +1,43 @@ + ++
Useful references: +
NOTE: The tar files in this distribution use GNU tar extensions,
+and must be untarred with a GNU compatible version of tar. The version
+of tar on Solaris and Mac OS X will not work with
+these files.
Tomcat 5.5 requires JRE 5.0 by default. Read the +RELEASE-NOTES and the RUNNING.txt file in the distribution for more details. +
+ +Packaging Details (or "What Should I Download?") +
Thank you for using Tomcat!. +
+The Apache Tomcat Project
http://tomcat.apache.org/
+
diff --git a/webapps/docs/META-INF/context.xml b/webapps/docs/META-INF/context.xml new file mode 100644 index 000000000..228184cb8 --- /dev/null +++ b/webapps/docs/META-INF/context.xml @@ -0,0 +1,12 @@ + + + +Before describing how to organize your source code directories, +it is useful to examine the runtime organization of a web application. +Prior to the Servlet API Specification, version 2.2, there was little +consistency between server platforms. However, servers that conform +to the 2.2 (or later) specification are required to accept a +Web Application Archive in a standard format, which is discussed +further below.
+ +A web application is defined as a hierarchy of directories and files +in a standard layout. Such a hierarchy can be accessed in its "unpacked" +form, where each directory and file exists in the filesystem separately, +or in a "packed" form known as a Web ARchive, or WAR file. The former format +is more useful during development, while the latter is used when you +distribute your application to be installed.
+ +The top-level directory of your web application hierarchy is also the
+document root of your application. Here, you will place the HTML
+files and JSP pages that comprise your application's user interface. When the
+system administrator deploys your application into a particular server, he
+or she assigns a context path to your application (a later section
+of this manual describes deployment on Tomcat). Thus, if the
+system administrator assigns your application to the context path
+/catalog, then a request URI referring to
+/catalog/index.html will retrieve the index.html
+file from your document root.
To facilitate creation of a Web Application Archive file in the required +format, it is convenient to arrange the "executable" files of your web +application (that is, the files that Tomcat actually uses when executing +your app) in the same organization as required by the WAR format itself. +To do this, you will end up with the following contents in your +application's "document root" directory:
+/WEB-INF/classes/. For example, a Java class named
+ com.mycompany.mypackage.MyServlet
+ would need to be stored in a file named
+ /WEB-INF/classes/com/mycompany/mypackage/MyServlet.class.
+ When you install an application into Tomcat (or any other
+2.2/2.3-compatible server), the classes in the WEB-INF/classes/
+directory, as well as all classes in JAR files found in the
+WEB-INF/lib/ directory, are made visible to other classes
+within your particular web application. Thus, if
+you include all of the required library classes in one of these places (be
+sure to check licenses for redistribution rights for any third party libraries
+you utilize), you will simplify the installation of your web application --
+no adjustment to the system class path (or installation of global library
+files in your server) will be necessary.
Much of this information was extracted from Chapter 9 of the Servlet +API Specification, version 2.3, which you should consult for more details.
+ +Like most servlet containers, Tomcat 5 also supports mechanisms to install +library JAR files (or unpacked classes) once, and make them visible to all +installed web applications (without having to be included inside the web +application itself. The details of how Tomcat locates and shares such +classes are described in the +Class Loader HOW-TO documentation. +For the purposes of our discussion, there are two locations that are commonly +used within a Tomcat 5 installation for shared code:
+Out of the box, a standard Tomcat 5 installation includes a variety +of pre-installed shared library files, including:
+++ +The description below uses the variable name $CATALINA_HOME + to refer to the directory into which you have installed Tomcat 5, + and is the base directory against which most relative paths are + resolved. However, if you have configured Tomcat 5 for multiple + instances by setting a CATALINA_BASE directory, you should use + $CATALINA_BASE instead of $CATALINA_HOME for each of these + references.
+
As mentioned above, the /WEB-INF/web.xml file contains the
+Web Application Deployment Descriptor for your application. As the filename
+extension implies, this file is an XML document, and defines everything about
+your application that a server needs to know (except the context path,
+which is assigned by the system administrator when the application is
+deployed).
The complete syntax and semantics for the deployment descriptor is defined +in Chapter 13 of the Servlet API Specification, version 2.3. Over time, it +is expected that development tools will be provided that create and edit the +deployment descriptor for you. In the meantime, to provide a starting point, +a basic web.xml file +is provided. This file includes comments that describe the purpose of each +included element.
+ +NOTE - The Servlet Specification includes a Document
+Type Descriptor (DTD) for the web application deployment descriptor, and
+Tomcat 5 enforces the rules defined here when processing your application's
+/WEB-INF/web.xml file. In particular, you must
+enter your descriptor elements (such as <filter>,
+<servlet>, and <servlet-mapping> in
+the order defined by the DTD (see Section 13.3).
++ +The description below uses the variable name $CATALINA_HOME + to refer to the directory into which you have installed Tomcat 5, + and is the base directory against which most relative paths are + resolved. However, if you have configured Tomcat 5 for multiple + instances by setting a CATALINA_BASE directory, you should use + $CATALINA_BASE instead of $CATALINA_HOME for each of these + references.
+
A /META-INF/context.xml file can be used to define Tomcat specific +configuration options, such as loggers, data sources, session manager +configuration and more. This XML file must contain one Context element, which +will be considered as if it was the child of the Host element corresponding +to the Host to which the The Tomcat configuration documentation contains +information on the Context element.
+ +In order to be executed, a web application must be deployed on +a servlet container. This is true even during development. +We will describe using Tomcat 5 to provide the execution environment. +A web application can be deployed in Tomcat by one of the following +approaches:
+$CATALINA_HOME/webapps/. Tomcat will assign a
+ context path to your application based on the subdirectory name you
+ choose. We will use this technique in the build.xml
+ file that we construct, because it is the quickest and easiest approach
+ during development. Be sure to restart Tomcat after installing or
+ updating your application.
+ $CATALINA_HOME/webapps/. When Tomcat is started, it will
+ automatically expand the web application archive file into its unpacked
+ form, and execute the application that way. This approach would typically
+ be used to install an additional application, provided by a third party
+ vendor or by your internal development staff, into an existing
+ Tomcat installation. NOTE - If you use this approach,
+ and wish to update your application later, you must both replace the
+ web application archive file AND delete the expanded
+ directory that Tomcat created, and then restart Tomcat, in order to reflect
+ your changes.
+ /manager, that allows you to
+ deploy and undeploy applications on a running Tomcat server without
+ restarting it. See the administrator documentation (TODO: hyperlink)
+ for more information on using the Manager web application.Ant
+ build tool that allow you to automate the execution of commands to the
+ "Manager" web application. These tasks are used in the Tomcat deployer.
+ Deploying your app on other servlet containers will be specific to each +container, but all containers compatible with the Servlet API Specification +(version 2.2 or later) are required to accept a web application archive file. +Note that other containers are NOT required to accept an +unpacked directory structure (as Tomcat does), or to provide mechanisms for +shared library files, but these features are commonly available.
+ +This manual includes contributions from many members of the Tomcat Project +developer community. The following authors have provided significant content: +
+The information presented is divided into the following sections:
+build.xml used by Ant to manage compilation.In order to use Tomcat 5 for developing web applications, you must first +install it (and the software it depends on). The required steps are outlined +in the following subsections.
+ +Tomcat 5.5 was designed to run on J2SE 5.0, but it can run on JDK 1.4 +as well, using the compatability package as detailed in the Tomcat +installation instructions. +
+ +Compatible JDKs for many platforms (or links to where they can be found) +are available at +http://java.sun.com/j2se/.
+ +Binary downloads of the Tomcat server are available from +http://jakarta.apache.org/binindex.cgi. +This manual assumes you are using the most recent release +of Tomcat 5. Detailed instructions for downloading and installing +Tomcat 5 are available here.
+ +In the remainder of this manual, example shell scripts assume that you have
+set an environment variable CATALINA_HOME that contains the
+pathname to the directory in which Tomcat 5 has been installed.
Binary downloads of the Ant build tool are available from +http://ant.apache.org/bindownload.cgi. +This manual assumes you are using Ant 1.4 or later. The instructions should +also be compatible with later versions, but this has not been tested.
+ +Download and install Ant from the distribution directory mentioned above.
+Then, add the bin directory of the Ant distribution to your
+PATH environment variable, following the standard practices for
+your operating system platform. Once you have done this, you will be able to
+execute the ant shell command directly.
Besides the required tools described above, you are strongly encouraged +to download and install a source code control system, such as the +Concurrent Version System (CVS), to maintain historical +versions of the source files that make up your web application. Besides +the server, you will also need appropriate client +tools to check out source code files, and check in modified versions.
+ +Detailed instructions for installing and using source code control +applications is beyond the scope of this manual. However, CVS server and +client tools for many platforms (along with documentation) can be downloaded +from http://www.cvshome.org.
+ +Congratulations! You've decided to (or been told to) learn how to +build web applications using servlets and JSP pages, and picked the +Tomcat server to use for your learning and development. But now what +do you do?
+ +This manual is a primer covering the basic steps of using Tomcat to +set up a development environment, organize your source code, and then +build and test your application. It does not discuss architectures or +recommended coding practices for web application development, +or provide in depth instructions on operating the development +tools that are discussed. References to sources of additional information +are included in the following subsections.
+ +The discussion in this manual is aimed at developers who will be using +a text editor along with command line tools to develop and debug their +applications. As such, the recommendations are fairly generic -- but you +should easily be able to apply them in either a Windows-based or Unix-based +development environment. If you are utilizing an Interactive Development +Environment (IDE) tool, you will need to adapt the advice given here to +the details of your particular environment.
+ +The following links provide access to selected sources of online +information, documentation, and software that is useful in developing +web applications with Tomcat.
+web.xml
+ Web Application Deployment Descriptor (Chapter 13). The Javadoc
+ API Documentation is included in the specification, and with the
+ Tomcat download.Although application development can take many forms, this manual proposes +a fairly generic process for creating web applications using Tomcat. The +following sections highlight the commands and tasks that you, as the developer +of the code, will perform. The same basic approach works when you have +multiple programmers involved, as long as you have an appropriate source code +control system and internal team rules about who is working on what parts +of the application at any given time.
+ +The task descriptions below assume that you will be using CVS for source +code control, and that you have already configured access to the appropriate +CVS repository. Instructions for doing this are beyond the scope of this +manual. If you are using a different source code control environment, you +will need to figure out the corresponding commands for your system.
+ + +In order to take advantage of the special Ant tasks that interact with the +Manager web application, you need to perform the following tasks +once (no matter how many web applications you plan to develop).
+$CATALINA_HOME/server/lib/catalina-ant.jar, which must be
+ copied in to the lib directory of your Ant installation.
+ manager assigned to
+ him or her. How such users are defined depends on which Realm you have
+ configured in Tomcat's conf/server.xml file -- see the
+ Realm Configuration HOW-TO for more
+ information. You may define any number of users (with any username
+ and password that you like) with the manager role.
+ The first step is to create a new project source directory, and customize
+the build.xml and build.properties files you will
+be using. The directory structure is described in the
+previous section, or you can use the
+sample application as a starting point.
Create your project source directory, and define it within your CVS
+repository. This might be done by a series of commands like this, where
+{project} is the name under which your project should be
+stored in the CVS repository, and {username} is your login username:
Now, to verify that it was created correctly in CVS, we will perform a +checkout of the new project:
+Next, you will need to create and check in an initial version of the
+build.xml script to be used for development. For getting
+started quickly and easily, base your build.xml on the
+basic build.xml file, included with this manual,
+or code it from scratch.
Until you perform the CVS commit, your changes are local to your own +development directory. Committing makes those changes visible to other +developers on your team that are sharing the same CVS repository.
+ +The next step is to customize the Ant properties that are
+named in the build.xml script. This is done by creating a
+file named build.properties in your project's top-level
+directory. The supported properties are listed in the comments inside
+the sample build.xml script. At a minimum, you will generally
+need to define the catalina.home property defining where
+Tomcat 5 is installed, and the manager application username and password.
+You might end up with something like this:
In general, you will not want to check the
+build.properties file in to the CVS repository, because it
+is unique to each developer's environment.
Now, create the initial version of the web application deployment
+descriptor. You can base web.xml on the
+basic web.xml file, or code it from scratch.
The edit/build/test tasks will generally be your most common activities +during development and maintenance. The following general principles apply. +As described in Source Organization, newly created +source files should be located in the appropriate subdirectory, under your +project source directory.
+ +Whenever you wish to refresh your development directory to reflect the +work performed by other developers, you will ask CVS to do it for you:
+To create a new file, go to the appropriate directory, create the file, +and register it with CVS. When you are satisfied with it's contents (after +building and testing is successful), commit the new file to the repository. +For example, to create a new JSP page:
+Java source code that is defined in packages must be organized in a
+directory hierarchy (under the src/ subdirectory) that
+matches the package names. For example, a Java class named
+com.mycompany.mypackage.MyClass.java should be stored in file
+src/com/mycompany/mypackage/MyClass.java.
+Whenever you create a new subdirectory, don't forget to
+register it with CVS.
To edit an existing source file, you will generally just start editing +and testing, then commit the changed file when everything works. Although +CVS can be configured to required you to "check out" or "lock" a file you +are going to be modifying, this is generally not used.
+ +When you are ready to compile the application, issue the following +commands (generally, you will want a shell window open that is set to +the project source directory, so that only the last command is needed):
+The Ant tool will be execute the default "compile" target in your
+build.xml file, which will compile any new or updated Java
+code. If this is the first time you compile after a "build clean",
+it will cause everything to be recompiled.
To force the recompilation of your entire application, do this instead:
+This is a very good habit immediately before checking in changes, to +make sure that you have not introduced any subtle problems that Javac's +conditional checking did not catch.
+ +To test your application, you will want to install it under Tomcat. The
+quickest way to do that is to use the custom Ant tasks that are included in
+the sample build.xml script. Using these commands might follow
+a pattern like this:
ant compile
+ command (or just ant, since this is the default). Make
+ sure that there are no compilation errors.
+ ant install
+ command. This tells Tomcat to immediately start running your app on
+ the context path defined in the app.path build property.
+ Tomcat does NOT have to be restarted for this to
+ take effect.ant compile command. This ensures that your changes will
+ be available to be saved (via cvs commit) later on --
+ the output build directory is deleted and recreated as necessary.
+ ant reload command.
+ ant remove command.Do not forget to commit your changes to the source code repository when +you have completed your testing!
+ +When you are through adding new functionality, and you've tested everything +(you DO test, don't you :-), it is time to create the distributable version +of your web application that can be deployed on the production server. The +following general steps are required:
+ant all from the project source
+ directory, to rebuild everything from scratch one last time.
+ cvs tag command to create an identifier for
+ all of the source files utilized to create this release. This allows
+ you to reliably reconstruct a release (from sources) at a later
+ time.ant dist to create a distributable
+ web application archive (WAR) file, as well as a JAR file containing
+ the corresponding source code.
+ dist directory using the
+ tar or zip utility, according to
+ the standard release procedures used by your organization.+ The example app has been packaged as a war file and can be downloaded + here (Note: make sure your browser doesn't + change file extension or append a new one). +
+
+ The easiest way to run this application is simply to move the war file
+ to your CATALINA_HOME/webapps directory. Tomcat will automatically
+ expand and deploy the application for you. You can view it with the
+ following URL (assuming that you're running tomcat on port 8080
+ as is the default):
+
+ http://localhost:8080/sample
+
+ If you just want to browse the code you can unpack the war file
+ with the jar command.
+
yTzLY{L9^gUarJ$bvv zKKsurGN4|JmomM2h^E?I8u_U5-9wJelKCzL-eDa(h)NAD{5~bu#v$g0+c&%v*=SMC zHV+gMTHH#6`Fv#AiqSHpc6=o=7-W(pXEPJk`jp3 zDg!_ND*FL4gRU(aXD%l#Y$wbb38zCE377XHNIyO+p{56#D)gV%C^fOYsJ9?<>v$IF zZy!A{GhLwG=XN84x@^49AAUR@>x3m#qB_e9-kMl`NjUGs36jhPzLIJG~R-K*- zi)8|f(>u@fg>!;-**hx)sht;~LvTsESVo7dukTdMn+-4818*^G+s0-He`)Nf?|2Rz z6Vdl%khI@pT57+sU`8MAF8^twXOHRO$8EKc$FBEs8d%;d8tdN=-2Kucb>Oa%CFLqp z5ekbQ#198HrhRs8AfCxt8Sj=m{#0I0j@xEkk-QgMGUgh-Cw|=tjk-Og9pyu8 zSz#<$l(2eFs{5XCcg1VwnDAAhCSwV~xwiyU!S+GH=7V5syW`O}a2O6Q$-fQR+1@zj z7weDX52yTZ?6g;oWw {5X|(qIgZ87c4@H~C#KQ-?b%|__AJ*H z3&F6^PY?GOc(#j+1>OG!e|WmsQ~e2_wrR2O_$m0eX?r@wY3~)A;s!=z{O4+aocMp7 z*wg%JXBEq%u{_piJ&m94;jy>}<{u1fM~~&s?mMyESBw?#OBVe}oz;h8sf(E2@fY>8 zEB&=iXZNL8Qu!45XVw0d EX*lQsIoFxUZ*=#Y= + */ + +public final class Hello extends HttpServlet { + + + /** + * Respond to a GET request for the content produced by + * this servlet. + * + * @param request The servlet request we are processing + * @param response The servlet response we are producing + * + * @exception IOException if an input/output error occurs + * @exception ServletException if a servlet error occurs + */ + public void doGet(HttpServletRequest request, + HttpServletResponse response) + throws IOException, ServletException { + + response.setContentType("text/html"); + PrintWriter writer = response.getWriter(); + + writer.println(""); + writer.println(""); + writer.println(" Sample Application Servlet Page "); + writer.println(""); + writer.println(""); + + writer.println(""); + writer.println("
"); + + writer.println(""); + writer.println(" "); + writer.println(""); + writer.println(" "); + writer.println(""); + writer.println("
"); + writer.println(" "); + writer.println("Sample Application Servlet
"); + writer.println("This is the output of a servlet that is part of"); + writer.println("the Hello, World application. It displays the"); + writer.println("request headers from the request we are currently"); + writer.println("processing."); + writer.println(""); + Enumeration names = request.getHeaderNames(); + while (names.hasMoreElements()) { + String name = (String) names.nextElement(); + writer.println("
"); + + writer.println(""); + writer.println(""); + + } + + +} diff --git a/webapps/docs/appdev/sample/web/WEB-INF/web.xml b/webapps/docs/appdev/sample/web/WEB-INF/web.xml new file mode 100644 index 000000000..95e2974d4 --- /dev/null +++ b/webapps/docs/appdev/sample/web/WEB-INF/web.xml @@ -0,0 +1,23 @@ + +"); + writer.println(" "); + } + writer.println("" + name + ": "); + writer.println("" + request.getHeader(name) + " "); + writer.println("+ + diff --git a/webapps/docs/appdev/sample/web/hello.jsp b/webapps/docs/appdev/sample/web/hello.jsp new file mode 100644 index 000000000..bf5957c5b --- /dev/null +++ b/webapps/docs/appdev/sample/web/hello.jsp @@ -0,0 +1,44 @@ + + +Hello, World Application ++ This is a simple web application with a source code organization + based on the recommendations of the Application Developer's Guide. + + ++ + +HelloServlet +mypackage.Hello ++ + +HelloServlet +/hello +Sample Application JSP Page + + + ++
+ ++ ++ ++
+ +Sample Application JSP Page
+This is the output of a JSP page that is part of the Hello, World +application. It displays several useful values from the request +we are currently processing. ++
+ + diff --git a/webapps/docs/appdev/sample/web/images/tomcat.gif b/webapps/docs/appdev/sample/web/images/tomcat.gif new file mode 100644 index 0000000000000000000000000000000000000000..32f7d809fbf745e814598cae44329394515c4879 GIT binary patch literal 1441 zcmV;S1z!3`Nk%w1VPpVD0J8u9?d|O+B_HU@b7@o+r;}NBZdk3Yt+ +Context Path: +<%= request.getContextPath() %> ++ +Path Information: +<%= request.getPathInfo() %> ++ +Query String: +<%= request.getQueryString() %> ++ +Request Method: +<%= request.getMethod() %> ++ +Servlet Path: +<%= request.getServletPath() %> +NkgMYcdmxvLDB z3k3wE& !9rlKuzGPY8;a- zBi9R*frQ3fG0HGx<2Ev@GR53BXC{m%G)VNLfCm<(3@d!93@{LZo_h$0rKE)ez={AR zgN!_u;fgt_k*ub?wkzoZv`}`Ys26raPFHm$%%BQT?K!Jd*G5{=2gTkKm85a{lvhHM zq%hB6VYfiyxgkqU9BLfq5RU * z2xlq)4&Xs{t#U;v$CFDj&NmWlD78X3I~6kLRd#bsr!75?4-CS74p59TK!KLf(JWu{ zs2v*S6ek^IHWKo4`3Crh2n(HYAT;)8-4 N!?Qv zNbi9l1PcSqNrRkkR)i&s4h%q4MFf=5oO?=aIRu&^c=rJw0k{aKqKI;+K%I56kbr3( zT^9|EFF~oypO-Kx)_@a?poNQXGV3h=heLGfTx2gvE6D=$^|mAimqz*Qx6i`q0EiqZ zX{>b0T!2TWRdNdMyA7Df-B5uH!I}}iQP5DR3&J@iyZ|@QpsyT3VN?@)6_TL?|JvGb zsR2JbFnZ>Em8}t9itts#&O#Tl#4NP8&A=BMaR>)2aO~^~Du2x3z~t)k)w%Hy0Wb|N zf17BMQk3jS7A-St-iA4YT*F$sb-+w3wCY?#(cjA3oB($E+yrXkHtlSK1V9}%g5$L? z4jxm=8#ISec@1urM2z!T!(E(>UmR+KtH75H9xTQonZA6CVvE^3jNEGf8?Dt{4bgYM zB8}xx0fgr)FOFfvw|E2Nu^`I-E1+OfSsnpQ6FIyCXB@^}X!r0#Q?Ha1Tqt*iKKj-* zbZu`Hd;Pnc4;4Jdc?Pd1&`RjkM63YE4c>dh0Ym&NF1B{PqBjP@eV!ELIakRle2Onf z!}iJE#RJVc2-}0!;N}Fr2?j5C`v(gnatq2yDd;Sm3ncK%`!KwXpTQ?+TmTTKffX(5 zeh_;T4ald1=DBZMCtzJt5WE%0q#&l0rBXp38ywnN(Lc7mOyr?ig~*8{&%esThK=OkAph3=niSAp+oHso + + Sample "Hello, World" Application + + + ++
+ ++ ++ ++
+ +Sample "Hello, World" Application
+This is the home page for a sample application used to illustrate the +source directory organization of a web application utilizing the principles +outlined in the Application Developer's Guide. +
To prove that they work, you can execute either of the following links: +
+ + +