The no. 1 solution for running JAVA applications like server applications.

Provides runtime container for running Java applications. Supporting implementation of different JAVA specifications like JSP, EJB. As input it request a JAVA code in war format. Load balancing is also available to provide better performance handling more client request into more server targets. It allows collecting debug outputs and logs.

It can be a bit slower then the native server implementation.

Great experience that facilitates developing, deploying, and running 3-tier enterprise applications using the Java platform.

Apache Tomcat supports the Java 2 Enterprise Edition (J2EE) stack including Java Servlets and Java Server Pages (JSPs). I employed Apache Tomcat for teaching Java Server-side web development and used it to deploy 3-tier enterprise applications using Android on the client-side, JSPs and Java Servlets on the application server side and the Oracle 12c database on the data persistence layer. Apache Tomcat on the application server layer proved very effective in running Java Server-side components and it was very easy to install and deploy. The Library loading structure was very simple and it boils down to placing the specific .Jar Java library in the lib folder on Apache Tomcat. Once the Java JDK is installed successfully, running Apache Tomcat consists of simply running a .bat file (on Windows) or a .sh shell script (on Mac or Linux)

The main issues I faced in Apache Tomcat is the need to rerun the server every time a new Servlet code was added to the WEB-INF folder. This reduces the efficiency and increase the time of development. This wasn't the case with JSP pages which are automatically converted and compiled into a Servlet in the Background. I wish to have a Tomcat bundle that includes the Server as well as the Java JDK. This would make it easier to deploy the server even on systems not having the Java JDK installed.

When I choose it, i develop a rest service.

Tomcat is great to deploy war projects developed by Jakarta or java enterprise edition.

Tomcat has a bad deployment management cli.

Great and reliable and flexible platform to work with for all these years.

It's open-source, and proven over 20+ years (and still going strong and actively maintained) of implementing the jsp and servlet specifications. Runs on the JVM, giving it flexibility to be deployed in most environments. Can be used to deploy simple microservices to big complex monoliths.

Like most software occasions security vulnerabilities are published ... (very rare in comparison to others), memory footprint quite vs jetty. Apart from that technology wise, requires jvm which in turn requires instance running os or docker image. (noting this in comparison to serverless technologies). Requires more architect work to scale (ie clustering, application load balancing etc, CI/CD integration).

Positive, have had lots of issues over the years but nothing serious enough for us to take the application down. Also, keep needing to redeploy with newer versions of Java which is understandable.

Ease of use and deployment Admin console with various panels that allows you go see in-depth of usages of the web applications running Fairly basic debugging with issues Restarting web apps is a one click button Auto starts with windows

Not a full-fledged application stack like for instance glassfish. For a large organisation, it's probably better to go with something that is a complete JAVA EE application server. Debugging is fairly basic and doesn't allow viewing of the actual error. Sometimes can have issues with memory leaks, which is hard to debug in live environment.