Externalize Configuration
Dropwizard has many options for configuring built-in components such as servlet engines or database data sources, as well as options for creating entirely new commands that can be run and configured using configuration files. We can also inject environment variables and system properties for those configuration types that we want to change based on the runtime environment. Like SpringBoot, we can bind entire property classes to specific objects. In this example, let's bind all helloapp.*properties to the HolaRestResource class. With SpringBoot, we can optionally write configuration files in a properties file with key-value tuples. We can also use YAML. For Dropwizard, we only have the YAML option.
So let's create a file called conf/applica-tion.yml in the root project (note that the conf directory needs to be created if it doesn't exist). We put our configuration files in the conf folder to help us organize the different configuration files for our project (the naming of the directory doesn't matter (that is, it doesn't have any traditional meaning to Dropwizard). Let's put it in the conf/application.yml file Add some configuration to:
In this example, we set the property to a specific value. What if we want to be able to override it based on some environmental conditions? We can override this by passing in a Java system variable like the Ddw.helloapp.say=guten tag. Note that the dw.* part of the system property name is important; it tells the Drop wizard to apply the value to one of the application's configuration settings. What if we want to override a property based on the value of an OS environment variable? Looks like a 3-8 example.
The pattern for the value of an attribute is to first look at an envi-ronment variable (if it exists). If the environment variable is not set, the default value provided is used. We also need to explicitly tell our application that we want to use the complement of environment variables. In the HolaDropwizardApplication class, initialize() method, see Example 3-9.
Now that we have the configuration set up, let's build the backing object for it. We purposefully created a sub-configuration called helloapp which allows us to name our configurations to organize them. We could leave it as a top-level configuration item, but since we didn't, let's see how to bind the application .yml file to the Dropwizard configuration object.
Let's create a new class called HelloSayingFactory located in the src/main/java/com/redhat/examples/Dropwizard/Resources directory:
This is a simple JavaBean with some validation (@NotEpty, from the Hibernate validator library) and Jackson (@JsonProperty) annotations. This class wraps all the configuration under the HELLOAPP configuration in a YAML file; for now, we just need "saying". When we first created the application, a HolaDropwi zardConfiguration class was created. Let's open the class and add a new HelloSayingFactory, as shown in Example 3-10.
Finally, we need to inject the configuration into the HolaRestRe source code (Example 3-11).
Since there is no magic dependency injection framework enforced, you need to update HolaDropwizardApplication to inject configuration into REST resources (Example 3-12).
Now, we should have a fairly sophisticated configuration injection capability at our disposal. In this example, we've intentionally made it a little more complicated to cover what you might do in a real use case. Also note that while the mechanism for connecting all of this is simpler, there is a very clear pattern here: bind our Java objects to the YAML configuration file and make everything very simple and intuitive without A complex framework needs to be utilized.
Let's run our application. To do this, let's update apor.xml to pass the new conf/application.yml file, as shown in Example 3-13.
Now we can run from the command line:
Enter http://localhost:8080/api/hola in the browser:
If we stop the microservice and export an environment variable, we should see a new statement:
Expose Application Metrics and Information
By default, metrics are enabled on the management port (8081 by default), but what does Dropwizard know specifically about our application? Let's add a couple of declarative annotations on HolaRestResources (Example 3-14).
We added the @Timed annotation, which tracks how long a call to the service takes. Additional notes for collecting metrics include:
@Metered
call service rate
@ExceptionMetered
throw exception rate
Build and restart your microservice and try accessing your service on http://localhost:8080/api/hola a few times. Then, if you navigate to http://localhost:8081/metrics?pretty=true, and scroll to the bottom (maybe different from yours), you should see metrics for our service.
How to Run This Outside of Maven?
Dropwizard packages our microservice into an executable jar. All we have to do is build our application and run it like this:
The next section is even more exciting! ! ! Stay tuned
original:
Author source: https://github.com/redhat-developer/microservices-by-example-source