Chapter 14. Deployment and
Throughout this topic, I have focused on teaching you the basics of JAX-RS and REST with
simple examples that have very few moving parts. In the real world, though, your JAX-RS
services are going to interact with databases and a variety of server-side component models.
They will need to be secure and sometimes transactional. Chapter 3 was a very simple ex-
ample of deploying JAX-RS within a Java EE environment. In this chapter, we'll look into
more deployment details of JAX-RS and how it integrates with Java EE and other compon-
JAX-RS applications are deployed within a standalone servlet container, like Apache Tom-
cat, Jetty, JBossWeb, or the servlet container of your favorite application server, like JBoss,
Wildfly, Weblogic, Websphere, or Glassfish. Think of a servlet container as a web server. It
understands the HTTP protocol and provides a low-level component model (the servlet API)
for receiving HTTP requests.
Servlet-based applications are organized in deployment units called Web ARchives (WAR).
A WAR is a JAR-based packaging format that contains the Java classes and libraries used by
the deployment as well as static content like images and HTML files that the web server will
publish. Here's what the structure of a WAR file looks like:
< any static
static content >
WEB - INF /
web . xml
Any files outside and above the WEB-INF/ directory of the archive are published and avail-
able directly through HTTP. This is where you would put static HTML files and images that
you want to expose to the outside world. The WEB-INF/ directory has two subdirectories.
Within the classes/ directory, you can put any Java classes you want. They must be in a Java
package structure. The lib/ directory can contain any application or third-party libraries that
will be used by the deployment. The WEB-INF/ directory also contains a web.xml deploy-
ment descriptor file. This file defines the configuration of the WAR and how the servlet con-
tainer should initialize it.