LIGHT

  • News
  • Docs
  • Community
  • Reddit
  • GitHub
Star

What's on this Page

    • Introduction
    • Handlers
    • Chains
    • Paths
    • Usage
    • Complete Sample

Multi Static Handler Chains

Configuring your microservice to support multiple static handler chains to define exactly which http handlers are invoked for a specific request.

Introduction

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.

Handlers

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:

handlers:
  - com.networknt.handler.sample.SampleHttpHandler1
  - com.networknt.handler.sample.SampleHttpHandler2
  - [email protected]

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.

Chains

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:

chains:
  secondBeforeFirst:
    - com.networknt.handler.sample.SampleHttpHandler2
    - com.networknt.handler.sample.SampleHttpHandler1
  thirdBeforeSecond:
    - third
    - com.networknt.handler.sample.SampleHttpHandler2

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

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.

For example:

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:

- com.networknt.handler.sample.SampleHttpHandler2
- com.networknt.handler.sample.SampleHttpHandler1
- [email protected]

Note: If the names of a chain and a handler ever conflict, the name of the chain will be used.

Usage

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.

Complete Sample

enabled: true

handlers:
  - com.networknt.handler.sample.SampleHttpHandler1
  - com.networknt.handler.sample.SampleHttpHandler2
  - [email protected]

chains:
  secondBeforeFirst:
    - com.networknt.handler.sample.SampleHttpHandler2
    - com.networknt.handler.sample.SampleHttpHandler1

paths:
  - path: '/test'
    method: 'get'
    exec:
      - secondBeforeFirst
      - third
  - path: '/v2/health'
    method: 'post'
    exec:
      - secondBeforeFirst
      - third
  • About Light
    • Overview
    • Testimonials
    • What is Light
    • Features
    • Principles
    • Benefits
    • Roadmap
    • Community
    • Articles
    • Videos
    • License
    • Why Light Platform
  • Getting Started
    • Get Started Overview
    • Environment
    • Light Codegen Tool
    • Light Rest 4j
    • Light Tram 4j
    • Light Graphql 4j
    • Light Hybrid 4j
    • Light Eventuate 4j
    • Light Oauth2
    • Light Portal Service
    • Light Proxy Server
    • Light Router Server
    • Light Config Server
    • Light Saga 4j
    • Light Session 4j
    • Webserver
    • Websocket
    • Spring Boot Servlet
  • Architecture
    • Architecture Overview
    • API Category
    • API Gateway
    • Architecture Patterns
    • CQRS
    • Eco System
    • Event Sourcing
    • Fail Fast vs Fail Slow
    • Integration Patterns
    • JavaEE declining
    • Key Distribution
    • Microservices Architecture
    • Microservices Monitoring
    • Microservices Security
    • Microservices Traceability
    • Modular Monolith
    • Platform Ecosystem
    • Plugin Architecture
    • Scalability and Performance
    • Serverless
    • Service Collaboration
    • Service Mesh
    • SOA
    • Spring is bloated
    • Stages of API Adoption
    • Transaction Management
    • Microservices Cross-cutting Concerns Options
    • Service Mesh Plus
    • Service Discovery
  • Design
    • Design Overview
    • Design First vs Code First
    • Desgin Pattern
    • Service Evolution
    • Consumer Contract and Consumer Driven Contract
    • Handling Partial Failure
    • Idempotency
    • Server Life Cycle
    • Environment Segregation
    • Database
    • Decomposition Patterns
    • Http2
    • Test Driven
    • Multi-Tenancy
    • Why check token expiration
    • WebServices to Microservices
  • Cross-Cutting Concerns
    • Concerns Overview
  • API Styles
    • Light-4j for absolute performance
    • Style Overview
    • Distributed session on IMDG
    • Hybrid Serverless Modularized Monolithic
    • Kafka - Event Sourcing and CQRS
    • REST - Representational state transfer
    • Web Server with Light
    • Websocket with Light
    • Spring Boot Integration
    • Single Page Application
    • GraphQL - A query language for your API
    • Light IBM MQ
    • Light AWS Lambda
    • Chaos Monkey
  • Infrastructure Services
    • Service Overview
    • Light Proxy
    • Light Mesh
    • Light Router
    • Light Portal
    • Messaging Infrastructure
    • Centralized Logging
    • COVID-19
    • Light OAuth2
    • Metrics and Alerts
    • Config Server
    • Tokenization
    • Light Controller
  • Tool Chain
    • Tool Chain Overview
  • Utility Library
  • Service Consumer
    • Service Consumer
  • Development
    • Development Overview
  • Deployment
    • Deployment Overview
    • Frontend Backend
    • Linux Service
    • Windows Service
    • Install Eventuate on Windows
    • Secure API
    • Client vs light-router
    • Memory Limit
    • Deploy to Kubernetes
  • Benchmark
    • Benchmark Overview
  • Tutorial
    • Tutorial Overview
  • Troubleshooting
    • Troubleshoot
  • FAQ
    • FAQ Overview
  • Milestones
  • Contribute
    • Contribute to Light
    • Development
    • Documentation
    • Example
    • Tutorial
“Multi Static Handler Chains” was last updated: August 28, 2019: fixes #138 remove example and move content to tutorial (ed7a7be)
Improve this page
  • News
  • Docs
  • Community
  • Reddit
  • GitHub
  • About Light
  • Getting Started
  • Architecture
  • Design
  • Cross-Cutting Concerns
  • API Styles
  • Infrastructure Services
  • Tool Chain
  • Utility Library
  • Service Consumer
  • Development
  • Deployment
  • Benchmark
  • Tutorial
  • Troubleshooting
  • FAQ
  • Milestones
  • Contribute