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 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 3 handlers, the first two being named by their fully qualified class, where as the
last 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 also, 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 once instance of the object is ever created.
If you needed multiple instance 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:
In this case, our microservice is supporting 2 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 end point, 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 backwards 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.