Initial commit

  -- The mercifully short story:

    # An academic by profession, but with lots of consulting experience as a programmer

      ## Full-time faculty member for 30-plus years in DePaul's College of Computing and Digital Media

         PhD from Northwestern University

      ## Long-term experience in programming production planning-scheduling systems (steel industry mostly) and

         product configuration systems (large-vehicle manufacturing mostly)

    # The hands-on approach is the hands-down best approach.

    # Feel free to contact me at: kalin@cs.depaul.edu

                                  http://condor.depaul.edu/mkalin

    Here's hoping that Tomcat meets your web-app publication needs.

    Marty Kalin

 -- Overview of the Apache Tomcat Web Server (http://tomcat.apache.org)

 # Tomcat is targeted at:

   -- Java programmers who need a really good web server to publish their web apps

   -- sys admins who need to support the publishing of Java web apps

 # Tomcat is a

       -- free

       -- production-grade

       -- lightweight	 

       -- open-source

       -- cross-platform  

       -- no-fuss

   web server.

   ## It's Java-centric: written in Java, designed to host Java web apps.

   ## It's easy to install on any system.

   ## Out of the box, with no configuration, it's good to go. Customization is usually in small pieces.

   ## Versioning is incremental: sensible improvements, no radical changes

 # We'll cover Tomcat in-depth and hands-on:

   -- installation

   -- starting/stopping

   -- app deployment

   -- management/customization

   -- security

   -- troubleshooting

 WAR files and URLs in Tomcat deployment: request mapping ('dispatching')

 # How does Tomcat map client requests to the appropriate 'resource' within a web app?

                 +--------------------+

    request----->| request dispatcher |----->requested resource

                 +--------------------+

   ## Bascally a two-step operation:

      -- First, find the appropriate WAR file.

      -- Second, find the resource (e.g., HTML page, Jave code) within the WAR file.

      -- If the requested WAR file doesn't exist, or the resource within it, we get the

         familiar "404 Not Found" response from the web server.

--------------------------------------------------------------------------------------------------------

 # The standard way to deploy a web app in Tomcat is to copy a WAR file (JAR file with a .war extension)

   to the TOMCAT_HOME/webapps tree (i.e., this directory or some subdirectory)

   ## The WAR file name is arbitrary.

   ## In this example, the deployed WAR file is named 'preds.war'.

   ## Contents of the deployed 'preds.war' file:

       ajax.xhtml                                 ## the identifier is 'ajax.jsf', a proxy for 'ajax.xhtml'

       WEB-INF/web.xml                            ## standard 'deployment descriptor' (optional)

       WEB-INF/faces-config.xml                   ## JSF deployment descriptor

       WEB-INF/classes/beans/Controller.class     ## backend JavaBean

       WEB-INF/classes/beans/Organization.class   ## ditto

       WEB-INF/classes/beans/Prediction.class     ## ditto

       WEB-INF/lib/javax.faces.jar                ## JSF implementation library

 # The client's URL includes the WAR file's name as the _first_ name in the URI-part of the URL.

   Example with 'preds.war' as the name of the deployed WAR file:

   'scheme'    port number  WAR file name  JSF script in the WAR file

        \               \      /           /

       http://localhost:8080/preds/ajax.jsf   ## URI starts with the / after the port number

              \_______/     \_____________/   ## URI = Uniform Resource Identifier: a name

                  /                \

       server's address       resource URI (Uniform Resource Identifier), aka 'path'

    ## In this example, /preds/ajax.jsf is the URI ('path to resource') -- what's being requested.

    ## The URI begins with '/preds' == a slash and then the WAR file's name _without_ the '.war' extension

 Assessment of the 'install Tomcat' exercise

 # Summary points:

   -- Unless there's an issue of disk space, it's more flexible to install the full JDK rather

      than just the JVM, as the JDK includes the JVM (JAVA_HOME/jre).

      ## In a production environment, it might be policy to have the JVM only, of course.

   -- In general, downloading core Tomcat as an archive, rather than as an installer,

      gives you more flexibility: complete control over where you put it, no hidden effects.

      ## If you want to have Tomcat run as a service, that's still possible, of course -- but

         the Windows installer makes this easier.

   -- The verification of "what's up on the Apache server got to my local machine" is straightforward:

      ## Compute the message digest of the downloaded file locally, and compare against the copy

         on the Apache download server.

      ## Doing both MD5 and SHA1 is about as easy as doing just one:

         -- Windows has the 'certUtil', Mac has the 'md5' and 'sha1' utils, and Linux has

            the 'md5sum' and 'sha1sum' utils.

   -- The verification of digital signatures is tricky, as you need:

      ## The signed resource: in this case, the downloaded archive or installer. This is easy.

      ## The digital signature: available as the 'pgp' tab on the Apache download site. No problem.

      ## A reliable copy of the signer's public key. Now things get tricky:

         -- A list of the signers is available as the 'KEYS' tab on the Apached load site.

         -- Public keys are available from sites such as MIT, used an the earlier lesson.

         -- The public keys themselves need verification...

-- Tomcat's directory structure

 # Tomcat can be installed (e.g., by unzipping a downloaded ZIP file) anywhere on the local system.

   ## For reference, TOMCAT_HOME is the top-level install directory.

      ### You could define an environment variable with this name, but it's not required.

 # Here's the directory structure for TOMCAT_HOME:

                              TOMCAT_HOME     ## contains LICENSE, NOTICE, RELEASE-NOTES, RUNNING.txt

                                    |

   +----------+----------+----------+----------+----------+---------+

   |          |          |          |          |          |         |

  bin        conf       lib        logs       temp       webapps   work

   *## bin:     scripts to start/stop Tomcat, etc.

    ## conf:    configuration files (XML files)

    ## lib:     Tomcat and 3rd-party libraries (JAR files)

    ## logs:    log files (many over time...)

    ## temp:    temporary files created using the Java File API

   *## webapps: deployed web apps (web sites, web services, web sockets,...)

    ## work:    Tomcat-compiled JSP scripts and other assets

   A star * marks the two subdirectories we care about most at the start.

  # More about TOMCAT_HOME/webapps

    ## It's the 'virtual base directory' for a deployed web app, e.g., 'preds.war'.

       ### The 'virtual' underscores that TOMCAT_HOME/webapps is _not_ part of the URI:

              http://localhost:8080/preds    ## no sign of TOMCAT_HOME/webapps

       ### TOMCAT_HOME/webapps can have arbitrarily many subdirectories to any level.

           Example: If 'preds.war' were deployed to TOMCAT_HOME/webapps/examples, then

	            the URL would be:

              http://localhost:8080/examples/preds

           -- To keep the URI part as simple as possible, I prefer to put all of my web apps

	      in TOMCAT_HOME/webapps rather than in a subdirectory thereof.