Errong Leng

Logging Transaction IDs in a Spring Web Application Execution Chain

By Errong Leng – 16 Apr 2024 – View online →

Introduction

In complex Spring Web applications, tracking requests through the execution chain can be challenging, especially in distributed environments. One effective way to enhance request traceability is by logging transaction IDs throughout the request lifecycle. In this guide, we'll explore how to implement transaction ID logging using SLF4J, Logback, and Spring Web's execution chain.

Implementing Custom Log Layout with Transaction ID: As discussed in our previous post, we can extend LayoutBase<ILoggingEvent> to create a custom layout that includes the transaction ID in log messages. We'll use a filter to extract the transaction ID from the request header and set it in the Mapped Diagnostic Context (MDC), making it available for logging.
Extracting Transaction ID from Request Header: Create a filter to intercept incoming requests and extract the transaction ID from the request header. Set the transaction ID in the MDC for logging purposes.
Customizing Log Layout with Transaction ID: Update the custom layout implementation to include the transaction ID in log messages. Access the transaction ID from the MDC and include it in the log message format.
Logging Transaction ID in Request Execution Chain: With the transaction ID set in the MDC, all log messages generated during the request execution chain will include the transaction ID. This enables easy tracking and correlation of log messages related to a specific request.

A sample implementation. With this implementation, the CustomLayout class serves as both a filter for extracting the transaction ID from the request header and setting it in the MDC, as well as a layout for formatting log messages with the transaction ID. This consolidation simplifies the codebase and eliminates the need for separate filter and layout classes.

import ch.qos.logback.classic.spi.ILoggingEvent;  import ch.qos.logback.core.LayoutBase;  import org.slf4j.MDC;  import javax.servlet.Filter;  import javax.servlet.FilterChain;  import javax.servlet.FilterConfig;  import javax.servlet.ServletException;  import javax.servlet.ServletRequest;  import javax.servlet.ServletResponse;  import javax.servlet.http.HttpServletRequest;  import java.io.IOException;    public class CustomLayout extends LayoutBase<ILoggingEvent> implements Filter {        private static final String TRANSACTION_ID_HEADER = "Transaction-ID";        @Override      public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)              throws IOException, ServletException {          try {              if (request instanceof HttpServletRequest) {                  HttpServletRequest httpRequest = (HttpServletRequest) request;                  String transactionId = httpRequest.getHeader(TRANSACTION_ID_HEADER);                  if (transactionId != null) {                      MDC.put("transactionId", transactionId);                  }              }              chain.doFilter(request, response);          } finally {              MDC.remove("transactionId");          }      }        @Override      public void init(FilterConfig filterConfig) throws ServletException {          // Initialization logic      }        @Override      public void destroy() {          // Cleanup logic      }        @Override      public String doLayout(ILoggingEvent event) {          String transactionId = MDC.get("transactionId");          return String.format("[%s] [%s] [%s] - %s%n",                  event.getLevel(),                  event.getLoggerName(),                  transactionId != null ? transactionId : "-",                  event.getMessage());      }  }

Conclusion

Logging transaction IDs in the request execution chain of a Spring Web application enhances traceability and simplifies debugging in distributed environments. By implementing a custom filter to extract transaction IDs from request headers and integrating them into the logging framework's MDC, developers can easily correlate log messages with specific requests. With this approach, monitoring and troubleshooting complex Spring Web applications become more manageable, leading to improved reliability and performance.

Crafting Custom Log Layouts with SLF4J and Logback: A Step-by-Step Guide

Post, Code and Quiet Time.

Crafting Custom Log Layouts with SLF4J and Logback: A Step-by-Step Guide

By Errong Leng – 16 Apr 2024 – View online →

Photo by Erik Kossakowski / Unsplash

Introduction

Customizing logging output is a common requirement in many applications, allowing developers to tailor log messages to specific formats and structures. SLF4J with Logback provides powerful capabilities for customizing logging behavior, including the ability to define custom layouts for log messages. In this guide, we'll explore how to implement LayoutBase<ILoggingEvent> to create a custom layout for log messages and integrate it with SLF4J and Logback.

Define Custom LayoutBase<ILoggingEvent> Implementation

To create a custom layout for log messages, we need to extend the LayoutBase<ILoggingEvent> class provided by Logback. This class allows us to define the format and structure of log messages.

import ch.qos.logback.classic.spi.ILoggingEvent;  import ch.qos.logback.core.LayoutBase;    public class CustomLayout extends LayoutBase<ILoggingEvent> {        @Override      public String doLayout(ILoggingEvent event) {          // Implement custom layout logic here          return formatLogMessage(event);      }        private String formatLogMessage(ILoggingEvent event) {          // Format log message based on event information          return String.format("[%s] [%s] - %s%n",                  event.getLevel(),                  event.getLoggerName(),                  event.getMessage());      }  }

Register Custom Layout in Logback Configuration

Next, we need to configure Logback to use our custom layout for logging. This is typically done in the logback.xml or logback-spring.xml configuration file.

<configuration>      <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">          <encoder>              <layout class="com.example.CustomLayout"/>          </encoder>      </appender>        <root level="DEBUG">          <appender-ref ref="STDOUT"/>      </root>  </configuration>

Integrate Custom Layout with SLF4J Logging

With the custom layout configured in Logback, we can now use SLF4J to log messages in our application. SLF4J provides a simple and flexible logging API that allows us to log messages at different log levels.

import org.slf4j.Logger;  import org.slf4j.LoggerFactory;    public class MyClass {        private static final Logger logger = LoggerFactory.getLogger(MyClass.class);        public void doSomething() {          // Log messages using SLF4J          logger.debug("Debug message");          logger.info("Info message");          logger.warn("Warning message");          logger.error("Error message");      }  }

Conclusion

Implementing a custom LayoutBase<ILoggingEvent> for logging with SLF4J and Logback allows developers to customize the format and structure of log messages according to their requirements. By following the steps outlined in this guide and defining a custom layout class, developers can create tailored logging output that meets the needs of their applications. With SLF4J and Logback, customizing logging behavior becomes straightforward, enabling more effective monitoring, debugging, and troubleshooting of applications.

Copying MDC Context Map in Web Clients: A Comprehensive Guide

Post, Code and Quiet Time.

Copying MDC Context Map in Web Clients: A Comprehensive Guide

By Errong Leng – 16 Apr 2024 – View online →

Photo by Library of Congress / Unsplash

Introduction

In distributed systems, maintaining context across microservices is crucial for effective logging and tracing. The Mapped Diagnostic Context (MDC) in logging frameworks like Logback or Log4j allows developers to propagate contextual information such as request IDs, user IDs, or correlation IDs across threads and services. When using web clients to make outgoing requests, it's essential to propagate the MDC context map to ensure consistency and traceability. This guide will provide a comprehensive overview of how to copy the MDC context map in web clients, ensuring seamless context propagation in distributed environments.

Configure MDC in Your Application: Before copying the MDC context map in web clients, ensure that MDC is properly configured in your application. This typically involves setting up MDC filters or interceptors to capture and propagate contextual information.
Use Interceptors or Filters in Web Clients: In both synchronous and asynchronous web clients, interceptors or filters can be used to capture the MDC context map from the current thread and propagate it to outgoing requests.
Example Implementation in Spring WebClient:

import org.slf4j.MDC;  import org.springframework.web.reactive.function.client.ExchangeFilterFunction;  import org.springframework.web.reactive.function.client.WebClient;  import reactor.core.publisher.Mono;    public class MdcPropagatingWebClient {        private final WebClient webClient;        public MdcPropagatingWebClient() {          this.webClient = WebClient.builder()                  .filter(mdcPropagatingFilter())                  .build();      }        private ExchangeFilterFunction mdcPropagatingFilter() {          return (request, next) -> Mono.deferContextual(contextView ->                  Mono.fromCallable(() -> MDC.getCopyOfContextMap())                          .doOnNext(mdcContext -> {                              if (mdcContext != null) {                                  MDC.setContextMap(mdcContext);                              }                          })                          .flatMap(mdcContext -> next.exchange(request))                          .doFinally(signalType -> MDC.clear())          );      }        public WebClient getClient() {          return webClient;      }  }

Integration with Other Web Clients: For other web clients, such as Apache HttpClient or OkHttp, similar approaches can be used to intercept outgoing requests and propagate the MDC context map.

Conclusion

Copying the MDC context map in web clients is essential for maintaining context and traceability in distributed systems. By following the guidelines outlined in this guide and implementing interceptors or filters in web clients, developers can ensure seamless context propagation across microservices. With consistent context propagation, logging and tracing become more effective, enabling easier debugging and monitoring of distributed applications.

Configuring Web Security in Spring Web and Spring WebFlux with Spring Boot 3.x and Java 17

Post, Code and Quiet Time.

Configuring Web Security in Spring Web and Spring WebFlux with Spring Boot 3.x and Java 17

By Errong Leng – 16 Apr 2024 – View online →

Photo by Yixian Zhao / Unsplash

Team is proactively working on spring boot 3.x upgrade and java 17. this post guide you how to migrate those Web Security Config in both Spring Web and Spring WebFlux.

Securing web applications is a critical aspect of modern software development. In Spring applications, configuring web security is made easy with the powerful Spring Security framework. With the release of Spring Boot 3.x and Java 17, developers can leverage the latest features and improvements for building secure web applications. This guide will demonstrate how to configure web security in both Spring Web and Spring WebFlux applications using Spring Security with Spring Boot 3.x and Java 17.

Configuring Web Security in Spring Web

  import org.springframework.context.annotation.Bean;  import org.springframework.context.annotation.Configuration;  import org.springframework.security.config.annotation.web.builders.HttpSecurity;  import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;  import org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer;  import org.springframework.security.web.SecurityFilterChain;  import org.springframework.security.web.util.matcher.AntPathRequestMatcher;    import static org.springframework.security.config.Customizer.withDefaults;    @EnableWebSecurity  @Configuration  public class WebSecurityConfig {        @Bean      public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {          return http                  .sessionManagement(s -> s.sessionFixation().newSession())                  .httpBasic(AbstractHttpConfigurer::disable)                  .cors(AbstractHttpConfigurer::disable)                  .csrf(AbstractHttpConfigurer::disable)                  .logout(AbstractHttpConfigurer::disable)                  .formLogin(AbstractHttpConfigurer::disable)                  .authorizeHttpRequests(requests -> requests.requestMatchers(                          new AntPathRequestMatcher("/paths/public/access", "GET")                   ).permitAll().anyRequest().authenticated())                  .oauth2ResourceServer(oauth2 -> oauth2.jwt(withDefaults())).build();      }  }

Configuring Web Security in Spring WebFlux

  import org.springframework.context.annotation.Bean;  import org.springframework.context.annotation.Configuration;  import org.springframework.security.config.annotation.web.reactive.EnableWebFluxSecurity;  import org.springframework.security.config.web.server.ServerHttpSecurity;  import org.springframework.security.web.server.SecurityWebFilterChain;    import static org.springframework.http.HttpMethod.GET;  import static org.springframework.security.config.Customizer.withDefaults;    @Configuration  @EnableWebFluxSecurity  public class WebSecurityConfig {    	@Bean  	SecurityWebFilterChain springSecurityFilterChain(ServerHttpSecurity http) {  		return http  				.httpBasic(ServerHttpSecurity.HttpBasicSpec::disable)  				.cors(ServerHttpSecurity.CorsSpec::disable)  				.csrf(ServerHttpSecurity.CsrfSpec::disable)  				.logout(ServerHttpSecurity.LogoutSpec::disable)  				.formLogin(ServerHttpSecurity.FormLoginSpec::disable)  				.authorizeExchange((authorize) -> authorize  						.pathMatchers(GET,  								"/paths/public/access")  						.permitAll()  						.anyExchange().authenticated()  				)  				.oauth2ResourceServer(oauth2 -> oauth2.jwt(withDefaults()))  				.build();  	}    }

Define Security Rules: Define security rules using the ServerHttpSecurity object, similar to configuring rules for Spring Web applications. Specify URL patterns, access permissions, and authentication mechanisms accordingly.

Oauth 2 Resource Server with JWT

spring:    security:      oauth2:        resourceserver:          jwt:            public-key-location: """            issuer-uri: ""

Conclusion

Configuring web security in Spring Web and Spring WebFlux applications with Spring Boot 3.x and Java 17 is straightforward with Spring Security. By following the guidelines outlined in this guide, you can effectively secure your web applications against unauthorized access and protect sensitive resources. Whether you're building traditional servlet-based applications or reactive applications, Spring Security provides the necessary tools and flexibility to meet your security requirements.

Implementing Filters in Spring Web and Spring WebFlux

Post, Code and Quiet Time.

Implementing Filters in Spring Web and Spring WebFlux

By Errong Leng – 16 Apr 2024 – View online →

Photo by J Lee / Unsplash

Introduction

Team is proactively working on spring boot 3.x upgrade and java 17. this post guide you how to migrate those Filters in both Spring Web and Spring WebFlux.

Filters are a fundamental aspect of web development, allowing developers to intercept and manipulate incoming requests and outgoing responses. In Spring applications, filters can be implemented to perform tasks such as logging, authentication, authorization, and request/response modification. This guide will demonstrate how to implement filters in both Spring Web and Spring WebFlux applications.

Implementing Filters in Spring Web

In Spring Web, filters are implemented by extending the javax.servlet.Filter interface and registering the filter with the servlet container using either web.xml or Servlet 3.0+ annotations.

import javax.servlet.*;  import java.io.IOException;    @Component  public class MyFilter implements Filter {        @Override      public void init(FilterConfig filterConfig) throws ServletException {          // Initialization logic      }        @Override      public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)              throws IOException, ServletException {          // Filter logic          chain.doFilter(request, response); // Proceed with the filter chain      }        @Override      public void destroy() {          // Cleanup logic      }  }

In the latest Java 17 release, the Jakarta EE namespace (jakarta.servlet) replaces the previous javax.servlet namespace.

import jakarta.servlet.*;
import jakarta.servlet.http.HttpServletRequest;

Create a Filter Class
Register the Filter: You can register the filter using either web.xml or Servlet 3.0+ annotations. With annotations, simply annotate the filter class with @Component.
Configure Filter Order (Optional): If you have multiple filters, you can specify their order using the @Order annotation or by implementing the Ordered interface.

Implementing Filters in Spring WebFlux

In Spring WebFlux, filters are implemented as WebFilter beans, which are registered with the WebFilterChain in the application configuration.

import org.springframework.web.server.ServerWebExchange;  import org.springframework.web.server.WebFilter;  import org.springframework.web.server.WebFilterChain;  import reactor.core.publisher.Mono;    @Component  public class MyWebFilter implements WebFilter {        @Override      public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {          // Filter logic          return chain.filter(exchange); // Proceed with the filter chain      }  }

Register the WebFilter Bean: The WebFilter bean is automatically registered with the WebFilterChain when the application starts.

Conclusion

Implementing filters in Spring Web and Spring WebFlux applications allows developers to intercept and manipulate HTTP requests and responses. Whether you're working with traditional servlet-based applications or reactive applications, Spring provides flexible mechanisms for implementing filters to meet your application's requirements. By following the guidelines outlined in this guide, you can effectively implement filters in your Spring applications to perform various tasks such as logging, authentication, and request/response modification.

Errong Leng

Logging Transaction IDs in a Spring Web Application Execution Chain

Introduction

Conclusion

Crafting Custom Log Layouts with SLF4J and Logback: A Step-by-Step Guide

Introduction

Define Custom LayoutBase<ILoggingEvent> Implementation

Register Custom Layout in Logback Configuration

Integrate Custom Layout with SLF4J Logging

Conclusion

Copying MDC Context Map in Web Clients: A Comprehensive Guide

Introduction

Conclusion

Configuring Web Security in Spring Web and Spring WebFlux with Spring Boot 3.x and Java 17

Configuring Web Security in Spring Web

Configuring Web Security in Spring WebFlux

Oauth 2 Resource Server with JWT

Conclusion

Implementing Filters in Spring Web and Spring WebFlux

Introduction

Implementing Filters in Spring Web

Implementing Filters in Spring WebFlux

Conclusion

@qzl/typed-i18n — Our Open-Source Typed i18n Project is Gaining Traction

Report Abuse

Labels