Often people develop web applications and deploy the resulting
.war file to Tomcat, or other servlet engine, or application
These servlet engines can come with their own baggage, which includes complex installation, configuration and administration. It also can include larger deployment footprints and runtime requirements. As servlet engines can sometimes be provided by other groups or departments, operational/procedural dependencies can be created between AD groups and web teams or system administrators.
Often what you want is that some application you have written should also listen on a port and serve web content too. Or perhaps the packaging and deployment framework within which you work doesn't play nicely with the operational constraints described above.
So for this, we can use Embedded Tomcat.
This makes Tomcat a part of your application.
Your application includes a few Tomcat related
Upon startup, the application creates a
customises it a little and starts it listening for web requests.
This package is really a demonstration of how this can work.
This package delivers three Maven projects.
mywar project is a simple web application.
It includes some static content and a servlet.
The servlet appears in three places (url-patterns), two requiring authenticated access, one also requiring confidential access (ie: SSL).
pom.xml produces a
.war as its result.
In principle, this
.war could be deployed to real Tomcat,
another servlet engine or application server, or even to the cloud.
wcet project depends on the appropriate Tomcat
This includes a
WCET class, which is what instantiates
Embedded Tomcat and customises it :-
staticmethod (call this first) to stop logging going to the console, and instead log it to N files of M MB each, and it also reformats the logging to something nicer than the
.warfile at a certain context location
The code explicitly avoids log rotation based on date, as runaway logging can fill a disk and take a system down before rotation kicks in. Instead it promises to keep within a disk size limit, and if runaway logging does occur, the worst that happens is that the logs don't go back as far in time as they would normally. Log numbers and sizes have defaults which can be overridden using properties.
mywebproc project instantiates a
WCET, registers My WAR into it, and starts listening.
.java file is therefore very short and unexciting.
It is likely that in real use, userids and passwords might be obtained from
a credential store and configured into the
pom.xml depends on the
mywar project and
Perhaps the most interesting thing is the use of an
assembly.xml to construct the file deployable asset.
It creates a
.zip file containing something like this :-
$ unzip -v mywebproc-0.1-SNAPSHOT-bin.zip Archive: mywebproc-0.1-SNAPSHOT-bin.zip Length Method Size Cmpr Date Time CRC-32 Name -------- ------ ------- ---- ---------- ----- -------- ---- 0 Stored 0 0% 12-30-2015 16:42 00000000 base/ 0 Stored 0 0% 12-30-2015 16:42 00000000 base/webapps/ 6210 Defl:N 4029 35% 12-29-2015 17:00 90e4c34b base/webapps/mywar.war 0 Stored 0 0% 12-29-2015 16:03 00000000 keystores/ 3169 Defl:N 1763 44% 12-29-2015 16:03 b6bb4483 keystores/webserver.jks 0 Stored 0 0% 12-30-2015 16:42 00000000 lib/ 2310271 Defl:N 2218543 4% 12-22-2015 08:50 c05864bb lib/ecj-4.4.2.jar 2633 Defl:N 1728 34% 12-30-2015 11:43 263f8f4d lib/mywebproc-0.1-SNAPSHOT.jar 9278 Defl:N 7866 15% 12-22-2015 08:50 7d239139 lib/tomcat-api-8.0.30.jar 81428 Defl:N 75803 7% 12-22-2015 08:50 2e7df4f8 lib/tomcat-el-api-8.0.30.jar 2829987 Defl:N 2639561 7% 12-22-2015 08:50 899530ad lib/tomcat-embed-core-8.0.30.jar 238012 Defl:N 220851 7% 12-22-2015 08:49 5a67ebfa lib/tomcat-embed-el-8.0.30.jar 642746 Defl:N 601626 6% 12-22-2015 08:50 0b0ade16 lib/tomcat-embed-jasper-8.0.30.jar 40845 Defl:N 37472 8% 12-22-2015 08:49 c919731d lib/tomcat-embed-logging-juli-8.0.30.jar 586127 Defl:N 552662 6% 12-22-2015 08:50 737756b0 lib/tomcat-jasper-8.0.30.jar 161367 Defl:N 149688 7% 12-22-2015 08:50 08ac7203 lib/tomcat-jasper-el-8.0.30.jar 61417 Defl:N 53013 14% 12-22-2015 08:50 b9f2c2ce lib/tomcat-jsp-api-8.0.30.jar 40845 Defl:N 37471 8% 12-22-2015 08:50 df578c52 lib/tomcat-juli-8.0.30.jar 244281 Defl:N 230652 6% 12-22-2015 08:50 f18bd858 lib/tomcat-servlet-api-8.0.30.jar 105125 Defl:N 96093 9% 12-22-2015 08:50 20a65a71 lib/tomcat-util-8.0.30.jar 201024 Defl:N 184439 8% 12-22-2015 08:50 4739696b lib/tomcat-util-scan-8.0.30.jar 8579 Defl:N 7563 12% 12-30-2015 16:42 66863fc5 lib/wcet-0.1-SNAPSHOT.jar 84 Defl:N 84 0% 12-30-2015 12:26 1a2d7e3f mywebproc 76 Defl:N 76 0% 12-30-2015 12:26 5b612a39 mywebproc.bat -------- ------- --- ------- 7573595 7121074 6% 24 files
Its important to spot that although
mywebproc-0.1-SNAPSHOT.jar was put in the
subdirectory, the assembly process has carefully arranged to put
mywar.war (named without a version suffix) in the
This is so the Java code that registers a
Tomcat has a fixed filename to refer to it by.
Note the inclusion of a couple of scripts
mywebproc.bat) to run the program.
You can imagine more sophisticated versions that could be used as
The intent of this structure is that you simply
the file, and run the script.
In reality, the installation process or the start script is likely
to need to add a
context.xml into the
subdirectory of the
This file contains things such as database connection definitions,
and is therefore likely to vary depending on the environment into
which the application is deployed.
$ unzip mywebproc-0.1-SNAPSHOT-bin.zip $ ./mywebproc
Point your browser at
Feel free to copy, its public domain. Caveat Emptor.