The structure to define your handlers configuration requires a few definitions:
handler: An instance of the undertow HttpHandler class. To help save on typing and increase readability, you have the option to name your handlers with the [email protected] format. You will see an example of this later on.
chain: A named list of handlers included to reduce repetition within the configuration.
exec: The execution chain to which a request will flow for a given path and method pair.
The first thing you will need to do within your config is to define a complete list of all the handlers that will be used in your microservice. It could look something like this:
In this case, we define three handlers, the first two being named by their fully qualified class, whereas the last one will be referenced by the given name third.
You will need to know and use the names of the handlers when defining reusable chains and execution lists.
It is important to note that each of the handlers within this list will be a singleton. So no matter how many times it’s referenced throughout the configuration, only one instance of the object is ever created. If you need multiple instances of the same class, you have the option to name them differently and reference them as such.
A chain defines an ordered list of handlers that can be referenced under a single name. This option is solely introduced as a means to save typing and increase readability.
To define a named chain, use the following format within the configuration:
As you can see, we reference the chains by the given name we provided in the handlers section. If you didn’t explicitly provide a name, the fully qualified class is used instead.
Paths define the execution that will occur as a request from the client is issued. They require three fields to be defined:
path: The URL path of the request.
method: The HTTP request method issued to this path.
exec: The execution list that will be triggered when the request is received.
paths:- path:'/test'method:'get'exec:- secondBeforeFirst- third- path:'/v2/health'method:'post'exec:- secondBeforeFirst- third
In this case, our microservice is supporting two request paths; one is a GET call at the /test endpoint and the other a post call on the /v2/health endpoint.
To expand on the execution that will occur when calling the /test endpoint, we can see that it first references the secondBeforeFirst chain, followed by the handler named third. So ultimately the call will be:
Note: If the names of a chain and a handler ever conflict, the name of the chain will be used.
To maintain backward compatibility, not including a handler.yml (or including one with enabled: false) will cause the previous structured config to be used instead (ie, a single execution flow for all requests, defined in service.yml).
However, to include it, the previous service.yml config for middleware will be ignored.
Usage is defined by including the handler.yml within your resources or config directory (or externalized and passed in), and setting enabled: true.