Currently, I am learning about Java web development.

A lot of it seems to simply be configuration to me, and I feel that my understanding is superficial because I only see the configuration (i.e. define your servlets and their mappings in the web.xml file, make custom Servlets by extending the HttpServlet class, instantiate Tomcat in the main method, etc.)

I want do know a bit more about what is actually going on under the hood - so I am in some need of some guidance.

To this end, I have done some cursory reading on Tomcat and servlets from the following links:

• What is a servlet
• Difference between embedded and not embedded
• Tomcat docs

So what I think I understand from this is that the servlets sit inside the Tomcat instance (a servlet container) and Tomcat handles all of the receiving all of the requests of the client and relaying them to the servlets. The servlets process the requests, send back a response, which Tomcat then sends back to the client. I suppose in the local setup I have, my machine would both be acting as the client and server.

Given the above I want to know:

1. How I can directly see and monitor the client's sending the request to Tomcat and verify that Tomcat has received the request? Essentially, how can I verify that this networking side of things is happening due to some implementation by Tomcat?
2. How does Tomcat parse the request information and send it to the servlets?
3. Is Tomcat a servlet container or a web server? Are these the same thing?
4. In the answer given in the second link regarding embedded vs. non-embedded, the answer states that an embedded server looks like a regular java program. Does this mean that for an embedded server, the server is in the java application while the web application is inside the server in the non-embedded case? Like the containment relationship is reversed? What does containment mean in the first place here?

Apologies for the numerous questions and thank you for helping to clarify.

CodePudding user response：

2. How does Tomcat parse the request information and send it to the servlets?

The Servlet specification explains that in detail. The spec is surprisingly easy to read; I suggest giving it a go.

As a simplified overview…

The job of a Servlet container is to process the incoming request, which is just a bunch of text. The Servlet container pulls out the various pieces and assembles them into a request object.

Likewise, the response produced by your servlet is packaged up as a response object. The Servlet container's job is to use all the info contained in that object to create a stream of text to be sent back to the client web browser.

The whole point of Servlet containers is to relieve the servlet-writing programmers of the need to know much of the details of HTTP and how to make a server. The Servlet container does all that work. In other words, the great thing about Servlet technology is that you the programmer need not ask this # 2 question of yours!

3. Is Tomcat a servlet container or a web server? Are these the same thing?

(a) both, (b) no.

No, servlet containers and web servers are two different kinds of software.

A web server handles:

• listening for incoming connections from clients (web browsers, etc.)
• sending response back to the client

A web server handles all the network traffic.

A Servlet container provides an environment in which relatively small chunks of code (servlets) can process a request and formulate a response. The small servlet does not have to handle network traffic, launching & shutting down, security, and all the other responsibilities of a full server. That explains the "-let" in "Servlet". Your servlet you write plugs into a container that does most of the heavy lifting required to be a server.

Some products, such as Tomcat & Jetty, can be composed of both a web server and a Servlet container.

Tomcat is composed mainly of three components: (1) Catalina, a servlet container, (2) Coyote, a web server, and (3) Jasper, a Jakarta Server Pages processor. See Wikipedia.

For most people's needs, the Coyote web server in Tomcat is a suitable web server. So you can use Tomcat as as all-in-one application server, handling both web traffic and servlets.

[web request] ➜ [Tomcat Coyote] ➜ [Tomcat Catalina] ➜ [your servlet]

Alternatively, some folks choose to use Tomcat only as a Servlet container, sitting behind a separate web server such as Apache HTTP Server. In such a case, Tomcat’s Coyote component goes unused. Instead, the separate web server handles client browser components, and processes incoming requests. If a request is asking for a static resource, the web server serves it out, without any involvement from Tomcat. If the request is asking for work that has been assigned to a servlet, then the separate web server passes the request on to Tomcat and its Catalina component. After your servlet produces a response, the response moves from Tomcat back to the external web server, which traffics the response onwards to the client web browser.

[web request] ➜ [Apache HTTP Server] ➜ [Tomcat Catalina] ➜ [your servlet]

4 … embedded vs. non-embedded …

Non-embedded is the classic situation, as originally envisioned when Servlet technology was first invented.

Back then, servers were few, expensive, and already in place permanently. The goal of Servlet technology was to make it easy for companies to keep those expensive servers busy by having many web applications running alongside each other.

Servlet technology allowed many different servlets to be running one one machine without stepping on each other, and without the programmers of each servlet having known anything about the other servlets being written. The Servlet container can stay up and running as servlets are deployed and un-deployed.

Fast forward, and we have cloud technology where servers are many, cheap, and convenient to create and destroy on-the-fly. So nowadays many people want to run their web applications separately, one web app per virtual machine or virtual service. Thus the need for embedded mode. We need an application that can be launched and shutdown on its own, to run one specific servlet (or multiple servlets meant to work together) without any other unrelated web apps.

One way to achieve this new goal is to package a web server and servlet container into a standalone Java app. A SysAdmin person can launch and quit this standalone app like any other Java app, without knowing anything about how to configure an on-going web server and Servlet container.