For our first Java EE deep dive, we will be covering Servlets. I don’t think it is a stretch to say that Servlet technology is the most useful and widely used feature in the entire Java EE stack.
The Basics
- First released in 1997.
- Servlets existed before the modern Java EE stack was codified.
- Used as the building block for many other Java EE technologies.
If you want the dry, super technical definition of a Servlet, it is a special kind of Java class that is able to respond to requests. In practice, however, people really only use them to respond to HTTP requests in web applications. In fact, if you read the latest specification document for Servlets, it pretty much talks about HTTP Servlets exclusively.
Anyway, I find it easier to use Servlets than to explain how to use them, but it is worth explaining anyway, as they serve as a good example on how most Java EE technologies are developed with and deployed.
Implementations (AKA Servlet Containers)
Implementations of the Servlet specification are called Servlet Containers. The role of the Servlet Container is to map HTTP requests to the appropriate Servlet class, as well as to manage the configuration and lifecycle of your Servlets. Generally speaking, you won’t use a Servlet Container all on its own. Instead, they’re typically included as a component in a Java-based web server. There are several of these servers out there, the most famous of which is Apache Tomcat. There are also lightweight, embedded servers such as Jetty, which is very useful for testing.
You can also use a full blown Java Application Server, such as JBoss or Glassfish.
Write against the API
The Servlet specification provides an API containing all the classes and interfaces defined in the spec. The API is distributed as a JAR file named servlet-api, and it is easy to include in a Maven or Gradle application. It is important to understand that the servlet-api JAR does not contain any concrete class implementations. It is simply interfaces and abstract classes. This ends up being OK however. Remember, every Servlet Container has to implement the API, so when you stick your application in a server, it will run against actual implementations of these classes. When developing, however, you just write and compile your code against the servlet-api JAR, since that’s all you will need.
That is, of course, if you run it in a server that supports Servlets. Run it elsewhere, and your application will probably explode.
Different Versions
The Servlet specification has gone through many revisions over the years, some of which have been significant. For example, the latest version, 3.0, adds new deployment options that make it easier to configure and launch Servlets. Make sure you don’t get your versions mixed up, otherwise things will break.
Web Applications
You don’t use Servlets by just dumping the classes into a server and calling it a day. Instead, you include them in a Java Web Application, which is then deployed to the server. Java Web Apps have a strict file structure and strict rules for configuration. Build tools such as Maven and Gradle make it easy to put them together, but it is still crucial to understand what they’re made of.
Just like Java libraries are packed up as JAR files, Java web applications are deployed as WAR files. The idea is the same, though the contents are slightly different. Here is what a typical WAR file will contain:
root_folder/
WEB-INF/
web.xml
lib/
classes/
<other static content>
Basically, everything that has to do with your Java code goes into the WEB-INF folder. This is partly for organizational purposes, and partly for security purposes. The web server does not allow clients to access the raw files contained within WEB-INF folder, so people can’t grab and decompile your Java classes.
Now, the details. The classes folder contains all of your Servlet classes (and any other code you wrote). The lib folder contains any 3rd party libraries and dependencies you’re using. Both of these folders are placed on the root of the Java classpath when your application runs.
The web.xml file is where you configure the web application. Here you can declare and configure your Servlets (and supporting classes), as well as other features such as security. We don’t have enough time in this post to go over all the details of the web.xml, but you will be seeing many examples of them in later entries.
PS - Servlet 3.0 allows you to write web apps which don’t require a web.xml file, and I’ll show you how to do this at least once, but for most of the examples I write I will use a web.xml file, as this will make the examples applicable to a wider variety of Servlet versions.
Aside from all the Java-related content, your web app. can also contain static HTML, Javascript and CSS files (you know, like a normal website). These can be placed at the root of the web application. Remember not to stick them in WEB-INF folder, otherwise you won’t be able to access them.
General Observations
The Servlet spec is mostly concerned with the routing of requests. It isn’t particularly concerned with what you do with them. The inside of a Servlet can be as complex or as simple as you need. This is the key to their power. They can be used for any number of different purposes, and indeed they are.
That’s another important point - chances are you will rarely need to write a Servlet from scratch. Most of the time you will rely on ones provided by other libraries and frameworks. This is completely normal; however, it is still important to know how they work.
In our next post, we will look at how to write and deploy a basic Servlet.