Download TomCat (binary) from https://tomcat.apache.org/download-90.

cgi
Download Ant (binary?) from https://ant.apache.org/

2. set ANT_HOME to /home/ravi/dev/ant/apache-ant-1.10.9

3. set CATLINA_HOME to /home/ravi/dev/tomcat/apache-tomcat-9.0.44

4. chmod +777 $CATALINA_HOME/bin/startup.sh shutdown.sh catalina.sh

5. goto http://localhost:8080/ . the tomcat inital page should be visible.

6. $CATALINA_HOME/bin/shutdown.sh

7. set CLASSPATH to include servlet-api.jar

In Intellij, how to add a jar to CLASSPATH is here

https://www.jetbrains.com/help/idea/2019.1/dependencies.html

This panel opens with CTRL-SHIFT-ALT-S. the '+' is a little hidden. look at the
right.
The same panel has the code output path.
To build the project, hit the Build button.

Structure of a webapplication directory

1. in "home" directory *of webapp* - *.html, *.jsp etc i.e html and jsp files
along with css, javascript, image etc files *that must be visible to the client
browser*
2. /WEB-INF/web.xml - an xml file that describes the servlets and other
components of your application + initialization parameters (??) + container managed
security constraints. (?? I think this is basically a (per application?/per tomcat
instance?) meta data file, 'describing' things)
3. /WEB-INF/classes - application specific classes, both servlets and non
servlets which are *not combined into jars*. The directory structure has to reflect
the name spacing. i.e, a class named com.mycompany.myPackage.myServlet will be in a
directory /WEB-INF/classes/com/mycompany/myPackage/myServlet.class
4. /WEB-INF/lib contains jar files that contain java classes your application
requires. can include, for example, jdbc drivers.

Implication: If all library classes are made available in /WEB-INF/classes or as

jars in /WEB-INF/lib, these are made available to your web application.

Note: the above is the 'unpacked' directory structure. These can also be packed
into a WAR archive for distribution.

tomcat and CLASSPATHS (from https://www.mulesoft.com/tcat/tomcat-classpath)

many CLASSPATH issues with TomCat. How to understand and fix them.
This problem is actually easy to fix. Tomcat documentation assumes that most people
always pick "the easiest" way of doing things.

In this article, How tomcat uses class paths.

why classpaths create problems for tomcat users

A CLASSPATH is an environment variable (or argument to an invocation of the jvm)

that tells the jvm where to find the classes and packages necessary to run a
program. The CLASSPATH is always set from a source outside the program itself,
which allows configuration. there are some naming conventions with directories
(??).

Why problems with tomcat?

1. Tomcat does not resolve CLASSPATH the same way as java programs
2. The way Tomcat resolves CLASSPATH changes with every major release
3. Tomcat's documentation and default configuration pushes a 'best' way of
doing things. No guidance is provided for common 'non default' classpath usages
like outside dependencies, shared dependencies, or multiple versions of the same
dependency.

1. Tomcat does not resolve CLASSPATH the same way as java programs
Tomcat aims to be selfcontained, to standardize the configuration and deployment of
webapps, while limiting access to libraries for security reasons. So Tomcat start
scripts *ignore CLASSPATH variable*, and generate their own classpaths when they
create Tomcat's "system" classloader.

Outline of Tomcat *6* startup process

1. the *jvm* bootstrap loader loads the core java libraries, located using the
JAVA_HOME variable.
2. startup.sh calling catalina.sh with the "start" parameter *overwrites* the
system classpath (with what? the value of 'start'?) and loads bootstrap.jar and
tomcat-juli.jar, these resources are visible only to tomcat
3. class loaders are created for each deployed context (??) which loads all class
and jar files contained in each applications, WEB-INF/classes and WEB-INF/lib
directories respectively and in that order. These resources are visible only to the
applicaton that loads them.
4. the Common classloader loads all classes and jars contained in the
$CATALINA_HOME/lib. These resources are visible to tomcat *and* all applications.

therefore (summary) instead of using the 'standard' (system?) classpath, Tomcat

resolves multiple classpaths using multiple 4 or more attributes, only one of which
(JAVA_HOME) is configured in the standard location.

Outline of tomcat *9* classloaders

the 'classloader tree' is

Bootstrap
|
System
|
Common
/\
/ \
Webapp1 Webapp2

the Bootstrap classloader contains the basic runtime classes provided by the JVM,
pivoting off JAVA_HOME
the System classloader is built from the following repositories.
1. $CATALINA_HOME/bin/bootstrap.jar - contains the main() method of Tomcat,
2. $CATALINA_HOME/bin/tomcat-juli.jar - logging implementation. juli =
java.util.logging implementation
3. $CATALINA_HOME/bin/common-daemons.jar - This jar is *not* present in the
CLASSPATH built by the catalina.sh scripts, but is referenced from the manifest
file of bootstrap.jar

the Common classloader contains(?) additional classes that are made visible to
*both* tomcat *and* *all* web applications.

Normally application classes should *not* be placed here.

The locations searched by this classloader depends on the common.loader
property in $CATALINA_BASE/conf/catalina.properties For the default value
( common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","$
{catalina.home}/lib","${catalina.home}/lib/*.jar"), it looks, in order, for
a. unpacked classes and resources in $CATALINA_BASE/lib
b. jar files in $CATALINA_BASE/lib
c. unpacked classes and resources in $CATALINA_HOME/lib
d. jarfiles in $CATALINA_HOME/lib

the webappX classloaders - a classloader is created for each web app that is
deployed in a single Tomcat instance.
all unpacked classes in /WEB-INF/classes directory of
your webapp, plus classes and resources in jar files under the WEB-INF/lib
directory of your web application and made visible to *each* web application, but
not to others

Server and shared 'advanced configurations' skipped. Look up as necessary.

To deploy a MyServlet.java to a tomcat and access it via the browser you should
1. create a directory for your web app with a WEB-INF subdirectory
2. create a classes directory and put MyServlet.class there
3. configure web.xml
4. configure conf.xml ?? something something , basically configure tomcat

3. configure web.xml

From http://tutorials.jenkov.com/java-servlets/web-xml.html

For a java servlet to be accessible from a browser, you should

1. tell the servlet container which servlets to deploy
2. what urls to map (the deployed) servlet to

*you do both by configuring web.xml*

Sample web.xml (just enough for HelloWorld servlet. Expand later with init
parameters from web.xml etc)

<?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">
<web-app>
<servlet>
....
</servlet>

<servlet-mapping>
.....
</servlet-mapping>
</webapp>

the servlet tag has two subtags, servlet-name and servlet-class, to give

<servlet>
<servlet-name>helloWorldServlet</servletname>
<servlet-class> com.mycompany.HelloWorldServlet<servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>helloWorldServlet</servlet-name> note this links to name above
that maps to a classe
<url-pattern>*/html</url-pattern> note: all urls ending in *.html is sent to
the servlet.
</servlet-mapping>

so the complete web.xml is

<?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">

<web-app>

<servlet>
<servlet-name>controlServlet</servlet-name>
<servlet-class>com.jenkov.butterfly.ControlServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>controlServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>