Dropwizard consists mostly of glue code to automatically connect and configure these components.

Organizing Your Project

In general, we recommend you separate your projects into three Maven modules: project-api,
project-client, and project-service.

project-api should contain your Representations; project-client should use
those classes and an HTTP client to implement a full-fledged client for your
service, and project-service should provide the actual service implementation, including
Resources.

Service

The main entry point into a Dropwizard service is, unsurprisingly, the Service class. Each
Service has a name, which is mostly used to render the command-line interface. In the
constructor of your Service you can add Bundles and Commands to
your service.

Configuration

Each Service subclass has a single type parameter: that of its matching Configuration
subclass. These are usually at the root of your service’s main package. For example, your User
service would have two classes: UserServiceConfiguration, extending Configuration, and
UserService, extending Service<UserServiceConfiguration>.

When your service runs Configured Commands like the server command, Dropwizard
parses the provided YAML configuration file and builds an instance of your service’s configuration
class by mapping YAML field names to object field names.

Note

If your configuration file doesn’t end in .yml or .yaml, Dropwizard tries to parse it
as a JSON file.

In order to keep your configuration file and class manageable, we recommend grouping related
configuration parameters into independent configuration classes. If your service requires a set of
configuration parameters in order to connect to a message queue, for example, we recommend that you
create a new MessageQueueConfiguration class:

Then, in your service’s YAML file, you can use a nested messageQueue field:

messageQueue:host:mq.example.comport:5673

The @NotNull, @NotEmpty, @Min, @Max, and @Valid annotations are part of Dropwizard’s
Validation functionality. If your YAML configuration file’s
messageQueue.host field was missing (or was a blank string), Dropwizard would refuse to start
and would output an error message describing the issues.

Once your service has parsed the YAML file and constructed its Configuration instance,
Dropwizard then calls your Service subclass to initialize your service’s Environment.

Note

You can override configuration settings by passing special Java system properties when starting
your service. Overrides must start with prefix dw., followed by the path to the
configuration value being overridden.

For example, to override the HTTP port to use, you could start your service like this:

java-Ddw.http.port=9090servermy-config.json

SSL

SSL support is built into Dropwizard. You will need to provide your own java
keystore, which is outside the scope of this document (keytool is the
command you need). There is a test keystore you can use in the
Dropwizard example project.

http:ssl:keyStore:./example.keystorekeyStorePassword:example# optional, JKS is default. JCEKS is another likely candidate.keyStoreType:JKS

Bootstrapping

Before a Dropwizard service can provide the command-line interface, parse a configuration file, or
run as a server, it must first go through a bootstrapping phase. This phase corresponds to your
Service subclass’s initialize method. You can add Bundles,
Commands, or register Jackson modules to allow you to include custom types as part
of your configuration class.

It’s important to keep the run method clean, so if creating an instance of something is
complicated, like the Thingy class above, extract that logic into a factory.

Health Checks

A health check is a runtime test which you can use to verify your service’s behavior in its
production environment. For example, you may want to ensure that your database client is connected
to the database:

If all health checks report success, a 200OK is returned. If any fail, a
500InternalServerError is returned with the error messages and exception stack traces (if an
exception was thrown).

All Dropwizard services ship with the deadlocks health check installed by default, which uses
Java 1.6’s built-in thread deadlock detection to determine if any threads are deadlocked.

Managed Objects

Most services involve objects which need to be started and stopped: thread pools, database
connections, etc. Dropwizard provides the Managed interface for this. You can either have the
class in question implement the #start() and #stop() methods, or write a wrapper class which
does so. Adding a Managed instance to your service’s Environment ties that object’s
lifecycle to that of the service’s HTTP server. Before the server starts, the #start() method is
called. After the server has stopped (and after its graceful shutdown period) the #stop() method
is called.

For example, given a theoretical Riak client which needs to be started and stopped:

If RiakClientManager#start() throws an exception–e.g., an error connecting to the server–your
service will not start and a full exception will be logged. If RiakClientManager#stop() throws
an exception, the exception will be logged but your service will still be able to shut down.

It should be noted that Environment has built-in factory methods for ExecutorService and
ScheduledExecutorService instances which are managed. See Environment#managedExecutorService
and Environment#managedScheduledExecutorService for details.

Bundles

A Dropwizard bundle is a reusable group of functionality, used to define blocks of a service’s
behavior. For example, AssetBundle provides a simple way to serve static assets from your
service’s src/main/resources/assets directory as files available from /assets/* in your
service.

Serving Assets

Either your service or your static assets can be served from the root path, but
not both. The latter is useful when using Dropwizard to back a Javascript
application. To enable it, move your service to a sub-URL.

http:rootPath:/service/*# Default is /*

Then use an extended AssetsBundle constructor to serve resources in the
assets folder from the root path. index.htm is served as the default
page.

Commands

Commands are basic actions which Dropwizard runs based on the arguments provided on the command
line. The built-in server command, for example, spins up an HTTP server and runs your service.
Each Command subclass has a name and a set of command line options which Dropwizard will use to
parse the given command line arguments.

Configured Commands

Some commands require access to configuration parameters and should extend the ConfiguredCommand
class, using your service’s Configuration class as its type parameter. Dropwizard will treat the
first argument on the command line as the path to a YAML configuration file, parse and validate it,
and provide your command with an instance of the configuration class.

Managed Commands

Managed commands further extend configured commands by creating a lifecycle process for your
service’s Managed Objects. All Managed instances registered with your service’s
Environment will be started before your command is run, and will be stopped afterward.

Tasks

A Task is a run-time action your service provides access to on the administrative port via HTTP.
All Dropwizard services start with the gc task, which explicitly triggers the JVM’s garbage
collection. (This is useful, for example, for running full garbage collections during off-peak times
or while the given service is out of rotation.)

Running a task can be done by sending a POST request to /tasks/{task-name} on the admin
port. For example:

You can grep for messages from a specific class or package really easily:

tail -f dw.log | grep 'com.example.dw.Thing'

You can even pull out full exception stack traces, plus the accompanying log message:

tail -f dw.log | grep -B 1 '^\!'

Configuration

You can specify a default logger level and even override the levels of
other loggers in your YAML configuration file:

# Logging settings.logging:# The default level of all loggers. Can be OFF, ERROR, WARN, INFO, DEBUG, TRACE, or ALL.level:INFO# Logger-specific levels.loggers:# Overrides the level of com.example.dw.Thing and sets it to DEBUG."com.example.dw.Thing":DEBUG

Console Logging

By default, Dropwizard services log INFO and higher to STDOUT. You can configure this by
editing the logging section of your YAML configuration file:

logging:# ...# Settings for logging to stdout.console:# If true, write log statements to stdout.enabled:true# Do not display log statements below this threshold to stdout.threshold:ALL

File Logging

Dropwizard can also log to an automatically rotated set of log files. This is the recommended
configuration for your production environment:

logging:# ...# Settings for logging to a file.file:# If true, write log statements to a file.enabled:false# Do not write log statements below this threshold to the file.threshold:ALL# The file to which current statements will be logged.currentLogFilename:./logs/example.log# When the log file rotates, the archived log will be renamed to this and gzipped. The# %d is replaced with the previous day (yyyy-MM-dd). Custom rolling windows can be created# by passing a SimpleDateFormat-compatible format as an argument: "%d{yyyy-MM-dd-hh}".archivedLogFilenamePattern:./logs/example-%d.log.gz# The number of archived files to keep.archivedFileCount:5# The timezone used to format dates. HINT: USE THE DEFAULT, UTC.timeZone:UTC

Syslog Logging

Finally, Dropwizard can also log statements to syslog.

Note

Because Java doesn’t use the native syslog bindings, your syslog server must have an open
network socket.

logging:# ...# Settings for logging to syslog.syslog:# If true, write log statements to syslog.enabled:false# Do not write log statements below this threshold to syslog.threshold:ALL# The hostname of the syslog server to which statements will be sent.# N.B.: If this is the local host, the local syslog instance will need to be configured to# listen on an inet socket, not just a Unix socket.host:localhost# The syslog facility to which statements will be sent.facility:local0

Testing Services

All of Dropwizard’s APIs are designed with testability in mind, so even your services can have unit
tests:

Banners

At Yammer, each of our services prints out a big ASCII art banner on startup. Yours should, too.
It’s fun. Just add a banner.txt class to src/main/resources and it’ll print it out when your
service starts:

Resources

Unsurprisingly, most of your day-to-day work with a Dropwizard service will be in the resource
classes, which model the resources exposed in your RESTful API. Dropwizard uses Jersey for this,
so most of this section is just re-hashing or collecting various bits of Jersey documentation.

Jersey is a framework for mapping various aspects of incoming HTTP requests to POJOs and then
mapping various aspects of POJOs to outgoing HTTP responses. Here’s a basic resource class:

This class provides a resource (a user’s list of notifications) which responds to GET and
POST requests to /{user}/notifications, providing and consuming application/json
representations. There’s quite a lot of functionality on display here, and this section will
explain in detail what’s in play and how to use these features in your service.

Paths

Important

Every resource class must have a @Path annotation.

The @Path annotation isn’t just a static string, it’s a URI Template. The {user} part
denotes a named variable, and when the template matches a URI the value of that variable will be
accessible via @PathParam-annotated method parameters.

For example, an incoming request for /1001/notifications would match the URI template, and the
value "1001" would be available as the path parameter named user.

If your service doesn’t have a resource class whose @Path URI template matches the URI of an
incoming request, Jersey will automatically return a 404NotFound to the client.

Methods

Methods on a resource class which accept incoming requests are annotated with the HTTP methods they
handle: @GET, @POST, @PUT, @DELETE, @HEAD, @OPTIONS, and even
@HttpMethod for arbitrary new methods.

If a request comes in which matches a resource class’s path but has a method which the class doesn’t
support, Jersey will automatically return a 405MethodNotAllowed to the client.

The return value of the method (in this case, a NotificationList instance) is then mapped to the
negotiated media type this case, our resource only supports
JSON, and so the NotificationList is serialized to JSON using Jackson.

Metrics

Every resource method can be annotated with @Timed, @Metered, and @ExceptionMetered.
Dropwizard augments Jersey to automatically record runtime information about your resource methods.

Parameters

The annotated methods on a resource class can accept parameters which are mapped to from aspects of
the incoming request. The *Param annotations determine which part of the request the data is
mapped, and the parameter type determines how the data is mapped.

For example:

A @PathParam("user")-annotated String takes the raw value from the user variable in
the matched URI template and passes it into the method as a String.

A @QueryParam("count")-annotated IntParam parameter takes the first count value from
the request’s query string and passes it as a String to IntParam‘s constructor.
IntParam (and all other com.yammer.dropwizard.jersey.params.* classes) parses the string
as an Integer, returning a 400BadRequest if the value is malformed.

A @FormParam("name")-annotated Set<String> parameter takes all the name values from a
posted form and passes them to the method as a set of strings.

What’s noteworthy here is that you can actually encapsulate the vast majority of your validation
logic using specialized parameter objects. See AbstractParam for details.

Request Entities

If you’re handling request entities (e.g., an application/json object on a PUT request), you
can model this as a parameter without a *Param annotation. In the
example code, the add method provides a good example of
this:

Jersey maps the request entity to any single, unbound parameter. In this case, because the resource
is annotated with @Consumes(MediaType.APPLICATION_JSON), it uses the Dropwizard-provided Jackson
support which, in addition to parsing the JSON and mapping it to an instance of Notification,
also runs that instance through Dropwizard’s Validation.

If the deserialized Notification isn’t valid, Dropwizard returns a 422UnprocessableEntity
response to the client.

Note

If your request entity parameter isn’t annotated with @Valid, it won’t be validated.

Media Types

Jersey also provides full content negotiation, so if your resource class consumes
application/json but the client sends a text/plain entity, Jersey will automatically reply
with a 406NotAcceptable. Jersey’s even smart enough to use client-provided q-values in
their Accept headers to pick the best response content type based on what both the client and
server will support.

Responses

If your clients are expecting custom headers or additional information (or, if you simply desire an
additional degree of control over your responses), you can return explicitly-built Response
objects:

returnResponse.noContent().language(Locale.GERMAN).build();

In general, though, we recommend you return actual domain objects if at all possible. It makes
testing resources much easier.

Error Handling

If your resource class needs to return an error to the client (e.g., the requested record doesn’t
exist), you have two options: throw a WebApplicationException or restructure your method to
return a Response.

If at all possible, prefer throwing WebApplicationException instances to returning
Response objects.

URIs

While Jersey doesn’t quite have first-class support for hyperlink-driven services, the provided
UriBuilder functionality does quite well.

Rather than duplicate resource URIs, it’s possible (and recommended!) to initialize a UriBuilder
with the path from the resource class itself:

UriBuilder.fromResource(UserResource.class).build(user.getId());

Testing

As with just about everything in Dropwizard, we recommend you design your resources to be testable.
Dependencies which aren’t request-injected should be passed in via the constructor and assigned to
final fields.

Testing, then, consists of creating an instance of your resource class and passing it a mock.
(Again: Mockito.)

Caching

The @CacheControl annotation will take all of the parameters of the Cache-Control header.

Representations

Representation classes are classes which, when handled to various Jersey MessageBodyReader and
MessageBodyWriter providers, become the entities in your service’s API. Dropwizard heavily
favors JSON, but it’s possible to map from any POJO to custom formats and back.

Basic JSON

Jackson is awesome at converting regular POJOs to JSON and back. This file:

Then make a FunkySerializer class which implements JsonSerializer<Funky> and a
FunkyDeserializer class which implements JsonDeserializer<Funky>.

snake_case

A common issue with JSON is the disagreement between camelCase and snake_case field names.
Java and Javascript folks tend to like camelCase; Ruby, Python, and Perl folks insist on
snake_case. To make Dropwizard automatically convert field names to snake_case (and back),
just annotate the class with @JsonSnakeCase:

Validation

Like Configuration, you can add validation annotations to fields of your
representation classes and validate them. If we’re accepting client-provided Person objects, we
probably want to ensure that the name field of the object isn’t null or blank. We can do
this as follows:

publicclassPerson{@NotEmpty// ensure that name isn't null or blank@JsonPropertyprivatefinalStringname;publicPerson(@JsonProperty("name")Stringname){this.name=name;}publicStringgetName(){returnname;}}

Then, in our resource class, we can add the @Valid annotation to the Person annotation:

@PUTpublicResponsereplace(@ValidPersonperson){// ...}

If the name field is missing, Dropwizard will return a text/plain422UnprocessableEntity response detailing the validation errors:

* name may not be empty

Advanced

More complex validations (for example, cross-field comparisons) are often hard to do using
declarative annotations. As an emergency maneuver, add the @ValidationMethod to any
boolean-returning method which begins with is:

@ValidationMethod(message="may not be Coda")publicbooleanisNotCoda(){return!("Coda".equals(name));}

Note

Due to the rather daft JavaBeans conventions, the method must begin with is (e.g.,
#isValidPortRange(). This is a limitation of Hibernate Validator, not Dropwizard.

Streaming Output

If your service happens to return lots of information, you may get a big performance and efficiency
bump by using streaming output. By returning an object which implements Jersey’s StreamingOutput
interface, your method can stream the response entity in a chunk-encoded output stream. Otherwise,
you’ll need to fully construct your return value and then hand it off to be sent to the client.

Testing

The dropwizard-testing module contains a number of helper methods for testing JSON parsing and
generating. Given a JSON fixture file (e.g., src/test/resources/fixtures/person.json), you can
test that a Person instance generates the same JSON as the fixture with the following:

importstaticcom.yammer.dropwizard.testing.JsonHelpers.asJson;importstaticcom.yammer.dropwizard.testing.JsonHelpers.jsonFixture;@TestpublicvoidproducesTheExpectedJson()throwsException{assertThat("rendering a person as JSON produces a valid API representation",asJson(person),is(jsonFixture("fixtures/person.json")));}

This does a whitespace- and comment-insensitive comparison of the generated JSON and the JSON in the
file. If they’re different, both JSON representations are helpfully displayed in the assertion
error.

Likewise, you can also test the parsing of the same JSON file to guarantee round-trip compatibility:

HTML Representations

Custom Representations

Sometimes, though, you’ve got some wacky output format you need to produce or consume and no amount
of arguing will make JSON acceptable. That’s unfortunate but OK. You can add support for arbitrary
input and output formats by creating classes which implement Jersey’s MessageBodyReader<T> and
MessageBodyWriter<T> interfaces. (Make sure they’re annotated with @Provider and
@Produces("text/gibberish") or @Consumes("text/gibberish").) Once you’re done, just add
instances of them (or their classes if they depend on Jersey’s @Context injection) to your
service’s Environment on initialization.

Configuration Defaults

Dropwizard has many configuration parameters, all of which come with good default values:

# HTTP-specific options.http:# The port on which the HTTP server listens for service requests.# Because Java cannot drop privileges in a POSIX system, these# ports cannot be in the range 1-1024. A port value of 0 will# make the OS use an arbitrary unused port.port:8080# The port on which the HTTP server listens for administrative# requests. Subject to the same limitations as "port". If this is# set to the same value as port, the admin routes will be mounted# under /admin.adminPort:8081# The minimum number of threads to keep running to process# incoming HTTP requests.minThreads:8# The maximum number of threads to keep running to process# incoming HTTP requests.maxThreads:1024# The type of connector to use.## Possible values are:# * blocking: Good for low-latency services with short request# durations. Corresponds to Jetty's# BlockingChannelConnector.# * nonblocking: Good for services which use Servlet 3.0# continuations or which maintain a large number# of open connections. Corresponds to Jetty's# SelectChannelConnector.# * legacy: Simple, java.io.Socket-based connector. Corresponds to# Jetty's SocketConnector.# * legacy+ssl: Corresponds to Jetty's SslSocketConnector.# * nonblocking+ssl: Corresponds to Jetty's# SslSelectChannelConnector.connectorType:blocking# The root path for the Jersey servlet.rootPath:"/"# The maximum amount of time a connection is allowed to be idle# before being closed.maxIdleTime:200s# The number of threads dedicated to accepting connections.acceptorThreads:1# The offset of the acceptor threads' priorities. Can be# [-5...5], with -5 dropping the acceptor threads to the lowest# possible priority and with 5 raising them to the highest priority.acceptorThreadPriorityOffset:0# The number of unaccepted requests to keep in the accept queue# before refusing connections. If set to -1 or omitted, the system# default is used.acceptQueueSize:-1# The maximum number of buffers to keep in memory.maxBufferCount:1024# The initial buffer size for reading requests.requestBufferSize:16KB# The initial buffer size for reading request headers.requestHeaderBufferSize:6KB# The initial buffer size for writing responses.responseBufferSize:32KB# The initial buffer size for writing response headers.responseHeaderBufferSize:6KB# Enables SO_REUSEADDR on the server socket.reuseAddress:true# Enables SO_LINGER on the server socket with the specified# linger time. By default, uses the system default.soLingerTime:null# The number of open connections at which the server transitions# to a "low-resources" mode. (Only valid if connectorType is# "nonblocking".)lowResourcesConnectionThreshold:25000# When in low-resources mode, the maximum amount of time a# connection is allowed to be idle before being closed. Overrides# maxIdleTime. (Only valid if connectorType is "nonblocking".)lowResourcesMaxIdleTime:5s# If non-zero, the server will allow worker threads to finish# processing requests after the server socket has been closed for# the given amount of time.shutdownGracePeriod:2s# If true, allows usage of the Server header in responses.useServerHeader:false# If true, allows usage of the Date header in responses.useDateHeader:true# If true, the HTTP server will prefer X-Forwarded headers over# their non-forwarded equivalents.useForwardedHeaders:true# If true, forces the HTTP connector to use off-heap, direct# buffers.useDirectBuffers:true# The hostname of the interface to which the HTTP server socket# will be bound. If omitted, the socket will listen on all# interfaces.bindHost:null# If specified, adds Basic Authentication to the admin port using# this username.adminUsername:null# If specified, adds Basic Authentication to the admin port using# this password. (Requires adminUsername to be specified).adminPassword:null# A map of servlet context parameter names to servlet context# parameter values.contextParameters:{}# Configuration parameters for GZIP encoding of response entities.gzip:# If true, all requests with gzip in their# Accept-Content-Encoding headers will have their response# entities encoded with gzip.enabled:true# All response entities under this size are not compressed.minimumEntitySize:256 bytes# The size of the buffer to use when compressing.bufferSize:8KiB# The set of user agents to exclude from compression.excludedUserAgents:[]# If specified, the set of mime types to compress.compressedMimeTypes:[]# SSL configuration parameters. If omitted, all of these parameters# will fall back to using JVM-specific defaults (except for# supportedProtocols).ssl:# The path to the Java Keystore which contains the server's SSL# certificate.keyStore:/path/to/keystore# The password for the keystore.keyStorePassword:"password"# The password for the key manager.keyManagerPassword:"password"# The keystore type.keyStoreType:JKS# If the trust store is a separate file, the path to the Java# keystore which contains certificates for the validation of# clients.trustStore:/path/to/truststore# The password for the trust store.trustStorePassword:"password"# The keystore type for the trust store.trustStoreType:JKS# Whether or not to require authentication by peer certificate.needClientAuth:true# Whether or not to prompt clients for their peer certificates.wantClientAuth:true# The alias of the certificate to use for SSL.certAlias:"cert"# If true, allows clients to renegotiate.## ONLY ALLOW CLIENTS TO RENEGOTIATE IF YOUR JVM HAS A FIX FOR# CVE-2009-3555. DOING OTHERWISE WILL MAKE YOUR SERVICE VULNERABLE# TO SSL RENEGOTIATION ATTACKS.allowRenegotiate:false# The path to the Certificate Revocation List.crlPath:/path/to/revocation-list# Whether or not to enable Certificate Revocation List# Distribution Points support.crldpEnabled:true# Whether or not to enable On-Line Certificate Status Protocol# support.ocspEnabled:true# The OCSP Responder URL.ocspResponderUrl:"http://blah"# The maximum length of a valid certificate verification path.maxCertPathLength:1# Whether or not peer certificates should be validated. Only# valid for PKIX trust stores.validatePeers:true# The name of the JCE provider to use for SSL.jceProvider:"SUN"# The list of supported SSL/TLS protocols. Dropwizard# intentionally disables SSLv2Hello for security reasons.supportedProtocols:["SSLv3","TLSv1","TLSv1.1","TLSv1.2"]# HTTP request log settings.requestLog:# Settings for logging to stdout.console:# If true, log requests to stdout.enabled:true# The time zone in which dates should be displayed.timeZone:UTC# A custom Logback format string.logFormat:null# Settings for logging to a file.file:# If true, log requests to a file.enabled:false# The time zone in which dates should be displayed.timeZone:UTC# A custom Logback format string.logFormat:null# The file to which statements will be logged.## If enabled is true, this must be specified.currentLogFilename:./logs/requests.log# If true, log files are rotated and archived.archive:true# When the log file rolls over, the file will be archived to# example-2012-03-15.log.gz, example.log will be truncated,# and new requests written to it.## If archive is true, this must be specified.archivedLogFilenamePattern:./logs/requests-%d.log.gz# The maximum number of log files to archive.archivedFileCount:5# Settings for logging to syslog.syslog:# If true, log requests to syslog.enabled:false# The hostname of the syslog server to which statements will# be sent.## N.B.: If this is the local host, the local syslog instance# will need to be configured to listen on an inet socket, not# just a Unix socket.host:localhost# The syslog facility to which statements will be sent.## Can be one of: {AUTH, AUTHPRIV, DAEMON, CRON, FTP, LPR,# KERN, MAIL, NEWS, SYSLOG, USER, UUCP, LOCAL0, LOCAL1,# LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7}.facility:local0# The time zone in which dates should be displayed.timeZone:UTC# A custom Logback format string.logFormat:null# Logging settings.logging:# The default level of all loggers. Can be OFF, ERROR, WARN, INFO,# DEBUG, TRACE, or ALL.level:INFO# Logger-specific levels.loggers:# Sets the level for 'com.example.app' to DEBUG.com.example.app:DEBUG# Settings for logging to stdout.console:# If true, write log statements to stdout.enabled:true# Do not display log statements below this threshold to stdout.threshold:ALL# The time zone in which dates should be displayed.timeZone:UTC# A custom Logback format string.logFormat:null# Settings for logging to a file.file:# If true, write log statements to a file.enabled:true# Do not write log statements below this threshold to the file.threshold:ALL# The time zone in which dates should be displayed.timeZone:UTC# A custom Logback format string.logFormat:null# The file to which statements will be logged.## If enabled is true, this must be specified.currentLogFilename:./logs/app.log# If true, log files are rotated and archived.archive:true# When the log file rolls over, the file will be archived to# app-2012-03-15.log.gz, example.log will be truncated,# and new statements written to it.## If archive is true, this must be specified.archivedLogFilenamePattern:./logs/app-%d.log.gz# The maximum number of log files to archive.archivedFileCount:5# Settings for logging to syslog.syslog:# If true, write log statements to syslog.enabled:false# The hostname of the syslog server to which statements will be# sent.## N.B.: If this is the local host, the local syslog instance# will need to be configured to listen on an inet socket, not just# a Unix socket.host:localhost# The syslog facility to which statements will be sent.## Can be one of: {AUTH, AUTHPRIV, DAEMON, CRON, FTP, LPR, KERN,# MAIL, NEWS, SYSLOG, USER, UUCP, LOCAL0, LOCAL1, LOCAL2, LOCAL3,# LOCAL4, LOCAL5, LOCAL6, LOCAL7}.facility:local0# The time zone in which dates should be displayed.timeZone:UTC# A custom Logback format string.logFormat:null