- Key Takeaways
- What is Dropwizard?
- Introducing Our Demo Application Domain
- Project Structure
- Application Configuration
- Application Class
- Creating a Representation of Domain Objects
- Create a Simple Resource
- Registering a Resource
- Building the Application
- Running the Application
- Summary
- Frequently Asked Questions (FAQs) about Getting Started with Dropwizard
Dropwizard is a framework for building RESTful web services in Java. In this tutorial we’re going to have a look at how to get started with developing a Dropwizard application by building a new service from scratch. This article is going to cover the very basics. The goal is to implement and run a Dropwizard application which is able to respond to an HTTP GET request.
After a short introduction to Dropwizard and our application domain, we will see how to create a new project, talk about its structure, and configure it. Later on we will implement a simple RESTful API before finally building and running your application.
The sample project is available on GitHub. Key commits are tagged and I’ll be referencing them throughout this post after each major change. If you feel that something is unclear and wish to see a snapshot of the whole project, feel free to check out the referenced tag.
The only prerequisites you need to have installed are Maven, JDK, and a text editor or IDE of your choice.
Key Takeaways
- Dropwizard is a Java framework for building RESTful web services, bundling together popular Java libraries and frameworks to simplify the process.
- A Dropwizard project is structured with Maven as the build tool, using the dropwizard-archetype to bootstrap the project from a template.
- Application configuration in Dropwizard is stored in a YAML file, which is parsed to build a new instance of a configuration class.
- The application class in Dropwizard is the entry point for the application, with its run method used to configure Dropwizard’s environment.
- Dropwizard applications are typically built as a fat JAR file, containing the classes from the project and all the libraries it depends on, making it easy to deploy and run.
What is Dropwizard?
As already stated, Dropwizard is a framework for building RESTful web services in Java. In essence, it is a glue framework which bundles together popular and battle-tested Java libraries and frameworks to make it easier to start building new RESTful web services.
Here’s an incomplete list of some of the libraries that Dropwizard uses.
- Jersey – reference implementation of JAX-RS, the API for RESTful web services in the Java platform
- Jackson – library for processing JSON data
- Jetty – HTTP server and Java Servlet container
- Metrics – library for capturing JVM- and application-level metrics for monitoring
- Guava – utility library
- Logback – logging library
Introducing Our Demo Application Domain
To get a better understanding of Dropwizard, we’re going to build a RESTful web service from the ground up. It is going to be a back-end for a hypothetical events app. Imagine you’ve moved to a new city and would like to plan your evening. This app will list events based on your search criteria and location. The back-end should be able to provide a list of events. It should also be possible to add new events and update existing events. To keep things simple, we’re going to exclude user authentication and authorization for now.
Project Structure
I’m going to use Maven as a build tool. In my opinion, the easiest way to get started with a new application is to create a project using the dropwizard-archetype
. Archetype is essentially a tool for bootstrapping a Maven project from a template.
Run the following command in your terminal to get started with a new Dropwizard project.
mvn archetype:generate \
-DarchetypeGroupId=io.dropwizard.archetypes \
-DarchetypeArtifactId=java-simple \
-DarchetypeVersion=1.0.2
As of October 2016, the latest version of Dropwizard is 1.0.2. Be sure to check the most recent version and update archetypeVersion
accordingly. Running the archetype:generate
command prompts you to enter some project specific fields (e.g. groupId, artifactId). When entering the project name, keep in mind that this field is used to generate application and configuration classes. Use CamelCase and do not insert spaces to make sure that the generated class names are going to be valid.
For example, I named the application Events. Therefore the generated classes are going to be named EventsApplication
and EventsConfiguration
. If I had used events-app as the name, event-appApplication
and event-appConfiguration
would have been generated. Unfortunately, these are invalid class names and the compiler will point that out to you.
On successful completion, This is what the generated folder structure looks like.
.
├── config.yml
├── pom.xml
├── README.md
└── src
├── main
│ ├── java
│ │ └── com
│ │ └── mydomain
│ │ ├── api
│ │ ├── cli
│ │ ├── client
│ │ ├── core
│ │ ├── db
│ │ ├── EventsApplication.java
│ │ ├── EventsConfiguration.java
│ │ ├── health
│ │ └── resources
│ └── resources
│ ├── assets
│ └── banner.txt
└── test
├── java
│ └── com
│ └── mydomain
│ ├── api
│ ├── client
│ ├── core
│ ├── db
│ └── resources
└── resources
└── fixtures
Application configuration is stored in config.yml
. We’re going to look at it in more detail in the next paragraph. Most of the meat is located in src/main/java
including the two aforementioned classes – EventsApplication
and EventsConfiguration
.
The following is an overview of which files should go into which folder:
api
– Here live your application representations, which are essentially the entities of your API. They are serialized and deserialized to JSON.cli
– Contains commands that can be executed from the command line. They are not covered in this tutorial.client
– HTTP client implementation of your API. For easy consumption of your API you can implement a client and place it here. We’re not going to do it in this tutorial.core
– This is where you implement your domain logic.db
– Classes related to database access.health
– Contains health checks. These are runtime tests which verify whether your application is behaving correctly.resources
– Jersey resources.
We’re not going to use all of these packages since I’d like to keep the tutorial on the easier side. Dropwizard isn’t strict about the package naming scheme. If you wish you can rename and restructure the package hierarchy to suit your needs better.
The initial project structure can be seen by checking out the starting-point
tag.
Application Configuration
Storing variables which might vary depending on the execution environment in a configuration file is considered to be a good practice. When running your application, Dropwizard expects to receive a configuration file as a command line argument. By default configuration files should be written in YAML. The parsed configuration fields are used to build a new instance of a configuration class.
For now, let’s keep the configuration file as straightforward as possible. There are two things I would like add. Firstly, let’s change the root path of our application so all REST endpoints will be served from /api/*
. The rootPath
parameter is one of many built-in configuration parameters Dropwizard has to offer, so we do not need to change any code to have it available.
Secondly, since we’re dealing with events, we care about the start time, which can be represented in many ways. Let’s add a date format configuration parameter, which enables us to control the output date format from a configuration file.
First, modify config.yml
and add the following configuration.
server:
rootPath: /api/*
dateFormat: yyyy-MM-dd'T'HH:mmZ
Of course we need to access the custom configuration parameter dateFormat
from within the running application. When Dropwizard is started, configuration fields are mapped to a configuration class’ member fields.
So let’s edit our configuration class and include the dateFormat
field. Open EventsConfiguration
and add the following lines:
@NotEmpty
private String dateFormat;
public String getDateFormat() {
return dateFormat;
}
An application shouldn’t trust an external configuration file to be correct. To help validate its correctness, we can use Hibernate Validator. The @NotEmpty
annotation makes sure the string is not empty. Otherwise Dropwizard fails to start.
Keep in mind that this does not check if the date format pattern is actually valid. It only checks if it is defined in the configuration file. You could create your own custom validator which will print out a nice error message at start-up if the pattern is invalid. To keep things simpler, I’m not going to tackle this issue at the moment.
Check out app-configuration
tag to see the project after configuration changes.
Application Class
This is what the generated application class looks like.
public class EventsApplication extends Application<EventsConfiguration> {
public static void main(final String[] args) throws Exception {
new EventsApplication().run(args);
}
@Override
public void run(EventsConfiguration configuration, Environment environment) {
}
@Override
public void initialize(Bootstrap<EventsConfiguration> bootstrap) {
}
}
When starting the service, the main
method inside the EventsApplication
class gets invoked. This is the entry point for a Dropwizard application. A new EventsApplication
object is created and its run
method is called. The run
method is used to configure Dropwizard’s environment.
This is the place to apply the date pattern used in our application. For that we configure Jackson’s ObjectMapper
, which will later (de)serialize the request and response parameters from Java classes to JSON and vice versa. Let’s modify its date format by explicitly creating a new instance of SimpleDateFormat
and passing it the pattern from the configuration object.
@Override
public void run(EventsConfiguration configuration, Environment environment) {
DateFormat eventDateFormat = new SimpleDateFormat(configuration.getDateFormat())
environment.getObjectMapper().setDateFormat(eventDateFormat);
}
Later we’re going to modify the run
method to register new resources.
The application class has one more method we need to look at although we’re not going to add any code inside it: initialize
is used to go through the application’s bootstrapping phase. Here you can add bundles and commands for example. Bundles are groups of reusable functionality – think of them as add-ons to your application. Commands can be used to create additional functionality that can be accessed from the command line.
Checkout date-format-configuration
tag to see the project after changes made in the application class.
Creating a Representation of Domain Objects
Representations are the entities of your API. They represent the current or the desired state of a resource. For example, when a client makes an HTTP GET request to the events resource, the server sends back a representation of the current state of events. Representations can be serialized to any format but we’re going to use JSON in this tutorial.
Let’s think about what fields we want to include in the events representation class. An event should have a name. Also, we need to know when and where the event is taking place. Hosts might want to add additional information about the event. This calls for a description field. It is a good idea to include an id as well since we want to make sure each event is uniquely identifiable.
Create a new Event
class in com.mycompany.api
(or whatever package naming scheme you are using).
public class Event {
private long id;
private String name;
private String description;
private String location;
private Date date;
//getters and setters omitted
}
In most cases using a string to represent a location might not be enough. You could create a Location
class which can hold more detailed information (e.g. latitude, longitude). Dropwizard will make sure nested objects are serialized correctly.
Check out event-representation
tag to see the project after creating a new representation class.
Create a Simple Resource
Under the hood, Dropwizard uses Jersey to build RESTful web services. Jersey is a reference implementation of JAX-RS (JSR 311 & JSR 339). A lot goes on in implementing resources and I don’t intend for this article to be a comprehensive overview of Jersey. If you wish to learn more, feel free to browse Jersey’s documentation.
To get started with Jersey, let’s create a resource for events. Additionally, we need to define a URL which can be used to access the resource and retrieve its current state.
Let’s create a very simple implementation of the events resource. The goal is to expose a URL for retrieving all events. For now we’re going to return dummy data. Create a new class called EventResource
in the resources
package.
@Path("events")
@Produces(MediaType.APPLICATION_JSON)
public class EventResource {
@GET
public List<Event> allEvents() {
Event e = new Event();
e.setDate(new Date());
e.setName("Birthday");
e.setId(1L);
e.setDescription("Please be on time!");
e.setLocation("221B Baker Street");
return Collections.singletonList(e);
}
}
The @Path
annotation specifies the URL root for this resource. In the next line we specify the representation format. Representation classes are serialized to JSON and returned to the client. EventResource
at its current state has only one method: allEvents
. It is annotated with the HTTP verb it should respond to. So for example, when a GET request to /events
is received by Dropwizard, allEvents
gets invoked. In REST speak, GET is used to retrieve a representation of the current state of a resource.
Inside the method a new Event
object is instantiated with dummy data. The event object is wrapped in a list which is then returned. I’m using singletonList
from the Collections class for convenience. Creating a new list manually and adding the element to the list would work perfectly as well.
To see the project after resource creation, check out event-resource
tag.
Registering a Resource
By default Dropwizard doesn’t know about resource classes and we need to tell it explicitly which resources to expose. Technically speaking, resources need to be registered with Dropwizard’s Jersey Environment. As mentioned earlier, resource registration can be done in the EventsApplication
class’ run
method.
Modify it to look like the following example.
@Override
public void run(EventsConfiguration configuration, Environment environment) {
DateFormat eventDateFormat = new SimpleDateFormat(configuration.getDateFormat())
environment.getObjectMapper().setDateFormat(eventDateFormat);
EventResource eventResource = new EventResource();
environment.jersey().register(eventResource);
}
The current state of the project can be seen by checking out register-resource
tag.
Building the Application
To run a Dropwizard application, it needs to be built first. It is recommended that you build your application as a fat JAR file. This is a JAR file that contains the classes from your project and all the libraries it depends on, so everything the application needs is bundled into a single file, which makes it easy to deploy and run. The same artifact can be promoted from test to staging to production while being sure there’s no version changes in libraries used.
If you followed the article and created a new project with dropwizard-archetype
then Maven is already configured to build a fat JAR file using the maven-shade-plugin.
Simply run the following command in the root of your project (the folder where pom.xml
is located).
mvn package
Running the Application
You can now execute the jar file as follows.
java -jar target/events-0.0.1-SNAPSHOT.jar server config.yml
For successful execution, we need to pass two command line arguments to Dropwizard. The first one, server
, instructs Dropwizard to start an HTTP server and run the service. The second argument is a configuration file which is required by the server command.
If the app started without any errors, point your browser (or a command line http tool such as curl) to http://localhost:8080/api/events
. The server should return with a valid response containing the following message body.
[{"id":1,"name":"Birthday","description":"Please be on time!","location":"221B Baker Street","date":"2016-10-03T12:09+0200"}]
Summary
By now you should have a basic idea what Dropwizard is about. With the help of existing libraries, Dropwizard enables developers to easily create new RESTful web services.
There’s a lot we did not cover. First of all, the requirements we set for our application are not met. At the moment, only dummy data is returned to the client. There’s going to be a follow-up article where we’re going to add additional features to the Events service and look into parts of Dropwizard we were not able to cover in this article.
Frequently Asked Questions (FAQs) about Getting Started with Dropwizard
How do I set up Dropwizard for the first time?
Setting up Dropwizard for the first time involves a few steps. First, you need to create a new Maven project and add Dropwizard dependencies to your pom.xml file. Next, you need to create a configuration class that will hold the configuration information from your YAML file. Then, you need to create a representation class, which is a simple Java class that Dropwizard can use to convert JSON objects. Finally, you need to create a resource class that will define the endpoints of your API.
What is the role of the YAML file in Dropwizard?
The YAML file in Dropwizard is used for configuration purposes. It contains settings that are used to configure the application’s components. For example, it can specify the server type, the application’s context path, the number of threads to use, and database connection details. The YAML file is read at runtime and its values are passed to the application’s Configuration class.
How can I create a Dropwizard project using Maven?
To create a Dropwizard project using Maven, you need to first create a new Maven project. Then, in the pom.xml file of your project, you need to add the Dropwizard dependencies. After that, you can create the necessary classes (like the Configuration class, the Application class, and the Representation class) and the YAML configuration file.
How do I define endpoints in Dropwizard?
In Dropwizard, endpoints are defined in resource classes. A resource class is a simple Java class that contains methods that correspond to different HTTP methods (like GET, POST, PUT, DELETE). Each method is annotated with a JAX-RS annotation that indicates the HTTP method and the path of the endpoint.
How can I handle exceptions in Dropwizard?
Dropwizard provides a built-in support for exception handling. You can create an ExceptionMapper class that maps a specific type of exception to a Response. The ExceptionMapper class should implement the ExceptionMapper interface and should be annotated with @Provider.
How do I test my Dropwizard application?
Dropwizard provides support for testing through the dropwizard-testing module. You can write unit tests for your resource classes using JUnit and Mockito. For integration tests, you can use the DropwizardAppRule class that starts your application before the tests and stops it after.
How do I deploy my Dropwizard application?
To deploy your Dropwizard application, you need to first package it into a fat JAR using the Maven package command. Then, you can run the JAR using the java -jar command, passing the server command and the path to your YAML configuration file.
How do I use a database with Dropwizard?
Dropwizard provides built-in support for using databases through the dropwizard-db module. You can configure a DataSourceFactory in your Configuration class and then use it to create a DAO class that interacts with the database.
How do I authenticate users in Dropwizard?
Dropwizard provides support for user authentication through the dropwizard-auth module. You can create an Authenticator class that validates user credentials and a Authorizer class that checks user permissions.
How do I monitor my Dropwizard application?
Dropwizard includes support for application metrics through the dropwizard-metrics module. You can monitor various aspects of your application, like request rates, response times, and exception rates. The metrics can be reported to various backends, like Graphite or Ganglia.
Software developer, hardware hacker, interested in machine learning, long distance runner.