DEV Community: Noel KAMPHOA

Centralized Logging for Java Apps With ELK and Docker Compose

Noel KAMPHOA — Sat, 23 Aug 2025 20:58:49 +0000

1. Introduction

Debugging a distributed Java application by SSH-ing into individual servers to grep through log files is a nightmare. What if you could search and visualize all your Spring Boot logs from a single, powerful dashboard? In this tutorial, we’ll walk through installing the ELK Stack (Elasticsearch, Logstash, Kibana) using Docker Compose—a perfect setup for development and testing. Then, most importantly, I'll show you exactly how to configure your Java application to send its logs straight to ELK. We will be installing the ELK Stack version 8.14.3.

2. Prerequisites

Basic Knowledge of Docker and Docker Compose. This tutorial uses Docker Desktop for Windows, but you can use any other Docker installation depending on your Operating System.
A running Docker and Docker Compose installation on your workstation.
A Java Application that you want to monitor. You may use this Spring Boot REST Application.

3. Directory Structure

First things first. Let's start by creating a directory where we will keep the configuration files of the three services(Elasticsearch, Logstash, Kibana) and the docker-compose.yml file. We will name that directory "elk".

Below is the directory structure of "elk":

C:\apps\elk>tree /f
Folder PATH listing for volume Windows
Volume serial number is XXX-XXXX
C:.
│   docker-compose.yml
│
├───elasticsearch
│   └───config
│           elasticsearch.yml
│
├───kibana
│   └───config
│           kibana.yml
│
└───logstash
    ├───config
    │       logstash.yml
    │
    ├───pipeline
    │       logstash.conf
    │
    └───sample-logs
            access_log.log

Make sure you create all these files and put them in the exact location under the "elk" directory.

4. Configuration files

Fill the configuration files of each of the three services with the content given below. We won't go deeper into the configurations themselves. You can refer to these tutorials to understand more about each service configuration: Elasticsearch, Logstash, and Kibana.

4.1. Elasticsearch

# Elasticsearch configuration file
# elasticsearch.yml
cluster.name: "docker-cluster"
network.host: 0.0.0.0

4.2. Logstash

Pipeline
We are configuring an input of type file. Logstash will output its data to Elasticsearch. We also print the data to the console for debugging purposes.
The file path refers to our application logs inside the container. We will bind that path to the application logs path outside the container in the Docker Compose file.

# Logstash configuration file logstash.conf
input{
    file {
        path => "/usr/share/logstash/logs/*.log" # Path inside the container
        start_position => "beginning"
        sincedb_path => "/dev/null"             # Optional: for testing, read from start every time
        codec => multiline {                    # CRITICAL for Java stack traces
          pattern => "^%{TIMESTAMP_ISO8601} "
          negate => true
          what => "previous"
        }
    }
}

filter {
   # Normalize CRLF
  mutate { gsub => ["message", "\r$", ""] }

  grok {
    match => {
      "message" => [
        "^%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:level}\s+--- \[(?<thread>[^\]]+)\]\s+%{JAVACLASS:logger}\s+method=%{WORD:http_method}\s+path=%{DATA:http_path}\s+status=%{NUMBER:http_status:int}\s+duration_ms=%{NUMBER:duration_ms:int}\s*:\s%{GREEDYDATA:msg}$"
      ]
    }
  }

  date {
    match    => [ "timestamp", "yyyy-MM-dd HH:mm:ss.SSS" ]
    target   => "@timestamp"
    timezone => "Europe/Paris"
  }

  mutate {
    rename => { 
        "msg" => "message" 
        "level"   => "[log][level]"
        "pid"     => "[process][pid]"
        "thread"  => "[process][thread][name]"
        "logger"  => "[log][logger]"
    }
  }
}

output {
   elasticsearch { 
       hosts => ["http://elasticsearch:9200"]
       user => "elastic"
       password => "${ELASTIC_PASSWORD}"  
       ssl_certificate_verification => false
       data_stream => false
       index => "logstash-%{+YYYY.MM.dd}"
   }
   # For debugging
   stdout { 
    codec => rubydebug 
   }

}

Settings file

# Logstash setting file logstash.yml
http.host: "0.0.0.0"
path.config: /usr/share/logstash/pipeline

4.3. Kibana

# Kibana configuration file
# kibana.yml
server.name: kibana
server.host: "0.0.0.0"
elasticsearch.hosts: [ "http://elasticsearch:9200" ]

5. The docker-compose file

In the docker-compose.yml file, you'll need to declare the three services and to connect them to the same network. We will call that network "elk".

Here is the content of our docker-compose.yml file:

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.14.3
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
    volumes:
      - ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml
      - ./elasticsearch/data:/usr/share/elasticsearch/data
    ports:
      - "9200:9200"
    healthcheck:
      test: ["CMD", "curl", "-s", "http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=50s"]
      interval: 30s
      timeout: 10s
      retries: 5      
    networks:
      - elk

  logstash:
    image: docker.elastic.co/logstash/logstash:8.14.3
    container_name: logstash
    environment:
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
    volumes:
      - ./logstash/config/logstash.yml:/usr/share/logstash/config/logstash.yml
      - ./logstash/pipeline/:/usr/share/logstash/pipeline/
      - C:/apps/logs:/usr/share/logstash/logs
    ports:
      - "5044:5044"
    networks:
      - elk
    depends_on:
      elasticsearch:
        condition: service_healthy

  kibana:
    image: docker.elastic.co/kibana/kibana:8.14.3
    container_name: kibana
    environment:
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}    
    volumes:
      - ./kibana/config/kibana.yml:/usr/share/kibana/config/kibana.yml
    ports:
      - "5601:5601"
    networks:
      - elk
    depends_on:
      elasticsearch:
        condition: service_healthy

networks:
  elk:
    driver: bridge

The following line C:/apps/logs:/usr/share/logstash/logs, bind our spring boot application logs path to a path inside the Logstash container. This step is CRITICAL to ensure the logs move from your application to Logstash, and Elasticsearch afterward.

Pro-tip: We have created an environment variable ELASTIC_PASSWORD in the host machine, and we are passing it to the three services under the environment setting.

5.1. Elasticsearch Service

The discovery type is set to "single-node" because we are in a testing environment and only have a single instance of Elasticsearch. We don't want the overhead of cluster formation and management.
Instead of leaving Elasticsearch to generate a password at startup, we have created a password and saved it in an environment variable. This way, we have total control over the password itself.
We use "Volume binding" to bind the configuration file that we created in the host machine to the one in the Docker image. We don't want to content of Elasticsearch indices to be lost if the service restarts. So we bind the data directory "/usr/share/elasticsearch/data" to a directory in our host machine "./elasticsearch/data".
We have created a health check for Elasticsearch to make sure it is ready before the other services start.
Lastly, we use port mapping to make Elasticsearch available on port 9200 from outside the container, and we attach the container to the "elk" network.

5.2. Logstash Service

Logstash has two types of configuration: pipeline and setting configurations. We also use "Volume binding" to bind these configuration files from our host machine to those in the container.
Logstash will be available on port 5044 and is attached to the "elk" network.
Elasticsearch has to be ready before Logstash can start. We use "depends_on" to configure that behavior.
Our Java Application ships its logs to "C:/apps/logs/springboot-rest.log" in the host machine. We have bound that directory to "/usr/share/logstash/logs" in the container.

5.3. Kibana Service

We also use "Volume binding" to bind the Kibana configuration file kibana.yml from our host machine to the one in the container.
Kibana will be available on port 5601 and is attached to the "elk" network.
Just like Logstash, Kibana depends on Elasticsearch to be able to start.

Pro-tip: When you configure Elasticsearch and Kibana using Docker-compose in this way, you don't need to enroll Kibana using an enrollment token as you would do if you had configured each of the services individually.

6. Start the Services

Once the configuration files are created and the docker-compose file is ready, use the following command to start the services:

docker-compose up

You can access the container logs using the following command:

docker-compose logs -f

7. Verify the installation

Look into each service's logs to ensure it started properly.
Elasticsearch

docker-compose logs -f elasticsearch

Logstash

docker-compose logs -f logstash

Kibana

docker-compose logs -f kibana

The option "-f" is used to have the logs in real-time, similarly to "tail -f"

8. Shipping Your Java Application Logs

Now that your ELK stack is running, let's get your Java logs into it. You don't need to change your existing logging statements(like logger.info()); you just need to ensure your application logs are written to a file.

8.1. For our Spring Boot REST Application using Logback:

Create or edit your logback-spring.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property name="LOG_FILE" value="C:/apps/logs/springboot-rest.log"/>
    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level --- [%thread] %logger{36} method=%X{method} path=%X{path} status=%X{status} duration_ms=%X{duration_ms} : %msg%n"/>

    <!-- Appender to write to the console -->
    <appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
        </encoder>
    </appender>

    <!-- Appender to write to a file -->
    <appender name="File" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_FILE}</file>
        <encoder>
            <pattern>${LOG_PATTERN}</pattern>
        </encoder>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>C:/apps/logs/springboot-rest.log.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>10MB</maxFileSize>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
    </appender>

    <!-- Root logging level -->
    <root level="info">
        <appender-ref ref="Console" />
        <appender-ref ref="File" />
    </root>
</configuration>

In this config, C:/apps/logs/springboot-rest.log is the location of our Spring Boot application logs. Feel free to adjust it accordingly.

Restart your Java application.

mvn spring-boot:run

Your logs will now be shipped to Logstash and appear in Kibana!

View the Logs in Kibana

Navigate to http://127.0.0.1:5601/ and you should see the Kibana welcome page. Kibana will invite you to create a DataView to be able to visualize the content of Elasticsearch indices.

At this stage, you need to create a Dataview to be able to visualize the content of Logstash indices. Follow this tutorial about debugging a Java application with Kibana to configure your Logstash dataview. Once everything is configured, you should see a screen similar to this:

That's it! You've set up a centralised logging infrastructure for your Java application.

9. Conclusion

You've now successfully built a powerful logging infrastructure for your Java projects. This Docker Compose setup is ideal for development and staging environments. By configuring your Java app to ship its logs to ELK, you've closed the loop and can now debug and monitor your applications more effectively than ever. You should be aware that the setup we did in this tutorial is only for a testing environment and is unsuitable for production. Kindly have a look at these recommendations if you plan to run the ELK Stack in production with Docker.

Originally published at: https://nkamphoa.com/devops-centralize-java-app-logs-with-elk-stack/

Exception Hierarchy in Java: Checked, Unchecked, and Errors

Noel KAMPHOA — Fri, 15 Aug 2025 18:49:59 +0000

Introduction

Understanding the Exception Hierarchy in Java is vital for writing reliable and maintainable code. Exceptions in Java are represented through a structured class hierarchy, rooted in the Throwable class. This hierarchy helps developers categorize and handle different error conditions efficiently, whether they are recoverable or not.

1. Root of the Hierarchy: Throwable

At the top of the Exception Hierarchy is the Throwable class. It has two direct subclasses:

Error: Represents serious problems that applications should not try to catch.
Exception: Indicates conditions that a program might want to catch.

Throwable
 ├── Error
 └── Exception

"To handle exceptions effectively, you must first understand where they come from."

2. Errors in Java

The Error class and its subclasses represent critical conditions, such as OutOfMemoryError or StackOverflowError, that are not meant to be caught by applications.

try {
    // Simulate error (not recommended in practice)
    throw new StackOverflowError("Critical Error");
} catch (Error e) {
    System.out.println("Caught an Error: " + e);
}

In most real-world scenarios, these are logged and allowed to propagate.

3. Checked Exceptions

Checked exceptions are subclasses of Exception (but not RuntimeException). They must be either caught or declared using the throws keyword.

Examples include:

IOException
SQLException

try {
    throw new java.io.IOException("File not found");
} catch (java.io.IOException e) {
    System.out.println("Handled checked exception: " + e.getMessage());
}

Checked exceptions encourage explicit error handling and are checked at compile-time.

4. Unchecked Exceptions

Unchecked exceptions extend the RuntimeException class.

These include:

They are not required to be declared or caught, but should still be handled when possible.

try {
    String s = null;
    s.length(); // Throws NullPointerException
} catch (NullPointerException e) {
    System.out.println("Caught unchecked exception: " + e.getMessage());
}

"Unchecked exceptions don't require you to catch them, but professional code often does."

5. Custom Exceptions

Developers can define their own exception classes by extending Exception or RuntimeException. This enables application-specific error reporting.

class CustomException extends Exception {
    public CustomException(String message) {
        super(message);
    }
}

Custom exceptions improve clarity and allow better abstraction for domain-specific problems.

6. Summary of Exception Hierarchy

Here's a summarized view of the Exception Hierarchy:

Throwable
 ├── Error
 │   └── OutOfMemoryError, StackOverflowError, etc.
 └── Exception
     ├── IOException, SQLException, etc. (Checked)
     └── RuntimeException
         ├── NullPointerException, IndexOutOfBoundsException, etc. (Unchecked)

Understanding this structure is critical when designing exception handling strategies. For deeper insights into practical handling, see our article on Handling exceptions in Java.

Conclusion

The Exception Hierarchy in Java provides a systematic way to represent and manage errors. Differentiating between errors, checked, and unchecked exceptions empowers developers to write robust and readable code. By mastering this hierarchy, developers can improve both the quality and clarity of their exception handling practices.

You can find the complete code of this article on GitHub.

Originally published at: https://nkamphoa.com/exception-hierarchy-in-java/

Understand the Factory Method Pattern in Java

Noel KAMPHOA — Sat, 21 Jun 2025 11:43:33 +0000

1. Introduction

In object-oriented programming, the Factory Method Pattern is a widely used creational design pattern that provides a robust solution for object instantiation. Instead of creating objects directly using constructors, this pattern suggests using factory methods to encapsulate the instantiation logic.

According to the Gang of Four (GoF),

"Factory Method lets a class defer instantiation to subclasses."

This design principle encourages loose coupling, flexibility, and adherence to the Open/Closed Principle—a cornerstone of clean code.

In this article, we will explore how the Factory Method Pattern works in Java, its benefits, and practical use cases. If you’re new to design patterns, consider reading our introduction to the SOLID principles for foundational context.

2. What Is the Factory Method Pattern?

The Factory Method Pattern defines an interface for creating an object, but allows subclasses to alter the type of objects that will be created. Rather than calling a constructor directly, a method (often named create or getInstance) is used to encapsulate the logic of object creation.

Key Characteristics

Delegates the instantiation logic to subclasses or factories
Encourages adherence to programming to interfaces, not implementations
Supports open-closed design by making it easy to introduce new product types

This pattern is especially useful in frameworks, plugins, and systems where the exact class of the object to be created isn't known until runtime.

3. Core Components

The pattern typically consists of:

Product: An interface or abstract class that declares the common behavior.
ConcreteProduct: Specific implementations of the Product interface.
Creator: An abstract class or interface declaring the factory method.
ConcreteCreator: Subclasses that implement the factory method to return instances of ConcreteProduct.

Understanding these components helps reinforce key OOP principles like abstraction and inheritance.

4. Example Implementation

Let’s consider a notification system that can send messages via Email or SMS. Instead of hard-coding object creation, we use a factory method to determine which notification service to instantiate.

// Product interface
public interface Notification {
    void notifyUser();
}

// ConcreteProduct implementations
public class EmailNotification implements Notification {
    public void notifyUser() {
        System.out.println("Sending an Email notification");
    }
}

public class SMSNotification implements Notification {
    public void notifyUser() {
        System.out.println("Sending an SMS notification");
    }
}

// Creator with factory method
public abstract class NotificationFactory {
    public abstract Notification createNotification();
}

// ConcreteCreators
public class EmailFactory extends NotificationFactory {
    public Notification createNotification() {
        return new EmailNotification();
    }
}

public class SMSFactory extends NotificationFactory {
    public Notification createNotification() {
        return new SMSNotification();
    }
}

Client Code

NotificationFactory factory = new EmailFactory();
Notification notification = factory.createNotification();
notification.notifyUser(); // Output: Sending an Email notification

This structure makes it easy to add new notification types without modifying the existing codebase, aligning with good design practices.

5. Advantages of the Factory Method Pattern

Loose Coupling: Classes depend on abstractions, not concrete implementations.
Scalability: New types can be added without changing existing code.
Code Clarity: Encapsulating creation logic simplifies client-side usage.
Enhanced Testing: Easier to mock and substitute implementations.

As your codebase grows, these benefits become increasingly significant.

6. Use Cases in Real Projects

Logging frameworks (e.g., log4j) use factory methods to create loggers.
GUI toolkits create widgets depending on the platform.
Connection factories in database access layers.

Wherever object creation logic needs to vary, the Factory Method Pattern offers an elegant solution.

7. Conclusion

The Factory Method Pattern in Java promotes clean code and flexible architecture by decoupling object creation from usage. It allows developers to design scalable and maintainable systems, especially in plugin-driven or layered applications.

You can find the complete code of this article here on GitHub.

Originally published on my blog at https://nkamphoa.com/factory-method-pattern-in-java/

Abstract Classes and Interfaces in Java

Noel KAMPHOA — Tue, 27 May 2025 12:56:46 +0000

Introduction

In Java, both abstract classes and interfaces allow you to define contracts and shared behavior for other classes. But when should you use one over the other?

This article explores the differences, use cases, and practical examples of abstract classes and interfaces to help you choose the right approach for your design.

1. What is an Interface?

An interface defines a contract. It contains method signatures that implementing classes must provide.

interface Animal {
    void eat();
    void sleep();
}

A class implements an interface like this:

class Dog implements Animal {
    public void eat() {
        System.out.println("Dog eats.");
    }

    public void sleep() {
        System.out.println("Dog sleeps.");
    }
}

Since Java 8, interfaces can also contain:

default methods with implementation
static methods
private methods (from Java 9+)

2. What is an Abstract Class?

An abstract class is a class that cannot be instantiated and may contain:

Abstract methods (no body)
Concrete methods (with body)
Fields and constructors

abstract class Vehicle {
    String brand;

    abstract void start();

    void fuelUp() {
        System.out.println("Filling fuel");
    }
}

A subclass must provide implementations for all abstract methods:

class Car extends Vehicle {
    void start() {
        System.out.println("Car is starting...");
    }
}

3. Key Differences

Feature	Interface	Abstract Class
Inheritance type	Implements	Extends
Multiple inheritance	Yes (can implement many interfaces)	No (can extend only one class)
Constructors	Not allowed	Allowed
Fields	`public static final` only	Any access modifier
Method body allowed	`default`, `static` (Java 8+)	Yes (concrete + abstract methods)
Use case	Capability or contract	Shared base behavior + state

4. When to Use What

Use interfaces when:
- You want to define a capability or contract (e.g., Comparable, Runnable)
- You need to support multiple inheritance
Use abstract classes when:
- You want to share common state or logic
- You want to provide a partially implemented blueprint

5. Real-World Example: Notification System

Let’s say you want to define a framework for sending notifications.

Option 1: Interface

interface Notifier {
    void send(String message);
}

Used when each implementation is completely independent (Email, SMS, Slack...).

Option 2: Abstract class

abstract class BaseNotifier {
    void log(String message) {
        System.out.println("LOG: " + message);
    }

    abstract void send(String message);
}

Used when you want to enforce logging or setup logic in all notifiers.

Conclusion

Both abstract classes and interfaces are powerful tools in Java. Use them deliberately:

Interfaces = “what a class can do”
Abstract classes = “what a class is and shares”

Understanding the distinction makes your code more expressive, reusable, and aligned with object-oriented best practices.

You can find the complete code of this article here in GitHub.

Originally published on my blog at: https://nkamphoa.com/abstract-classes-and-interfaces-in-java/

Single Responsibility Principle in Java

Noel KAMPHOA — Sat, 17 May 2025 14:46:41 +0000

Introduction

The Single Responsibility Principle (SRP) is the “S” in the SOLID principles of object-oriented design. It’s often mentioned, sometimes misunderstood, and rarely applied correctly in large Java applications.

Definition: A class should have only one reason to change.

In practice, this means a class should encapsulate a single, well-defined responsibility — not “one method” or “one functionality,” but one axis of change.

In this article, we'll go beyond trivial examples and explore real-world SRP violations, how to spot them, and how to refactor for maintainability and testability.

1. A Real-World Example: User Registration

Consider the following UserService class:

public class UserService {

    public void register(String email, String password) {
        if (!email.contains("@")) {
            throw new IllegalArgumentException("Invalid email");
        }

        String hashed = BCrypt.hash(password);
        User user = new User(email, hashed);

        userRepository.save(user);

        sendWelcomeEmail(user);
    }

    private void sendWelcomeEmail(User user) {
        // SMTP connection setup
        // Template rendering
        // Email dispatch
    }
}

This looks fine... until you need to:

Add a new hashing algorithm
Change email provider
Handle registration for third-party OAuth

SRP is violated. Why?

2. Identifying the Responsibilities

The UserService class currently does at least three things:

Validates input
Manages user persistence
Handles email communication

Each of these concerns could change independently.

Marketing wants to change email templates.
Security wants a new hashing policy.
DevOps wants to decouple SMTP config.

All are reasons to change. That’s your SRP alarm.

3. Refactoring for SRP

Let’s extract each responsibility into its own class.

✅ Extract validation:

public class RegistrationValidator {
    public void validate(String email) {
        if (!email.contains("@")) {
            throw new IllegalArgumentException("Invalid email");
        }
    }
}

✅ Extract password logic:

public class PasswordEncoder {
    public String encode(String password) {
        return BCrypt.hash(password);
    }
}

✅ Extract email logic:

public class WelcomeMailer {
    private final EmailClient client;

    public WelcomeMailer(EmailClient client) {
        this.client = client;
    }

    public void send(User user) {
        client.send(user.getEmail(), "Welcome", "Thanks for joining!");
    }
}

🔁 Updated `UserService`:

public class UserService {

    private final UserRepository userRepository;
    private final RegistrationValidator validator;
    private final PasswordEncoder encoder;
    private final WelcomeMailer mailer;

    public UserService(UserRepository userRepository,
                       RegistrationValidator validator,
                       PasswordEncoder encoder,
                       WelcomeMailer mailer) {
        this.userRepository = userRepository;
        this.validator = validator;
        this.encoder = encoder;
        this.mailer = mailer;
    }

    public void register(String email, String password) {
        validator.validate(email);
        String hashed = encoder.encode(password);
        User user = new User(email, hashed);
        userRepository.save(user);
        mailer.send(user);
    }
}

Now:

Each class has one reason to change
You can test independently
Replacing email providers or validators becomes trivial

4. When Is SRP Worth It?

Over-applying SRP can lead to fragmentation in small projects. But in medium to large systems, SRP is essential for:

Isolated unit testing
Team collaboration
Clean domain boundaries

A good rule: When a class grows past 50–70 lines and touches multiple infrastructure layers, SRP may be at risk.

4.5. SRP vs. Microservices: A Note

A common misunderstanding is to equate the Single Responsibility Principle (SRP) with microservices — as if one microservice should only do one thing. But SRP applies at the class level, not the system level.

In fact, it’s possible (and common) to:

Have a monolith that applies SRP cleanly within each service or module.
Build a microservice that violates SRP internally by mixing responsibilities into one giant class (e.g., a UserService that also sends emails, logs metrics, and transforms DTOs).

SRP helps define cohesion within a module or microservice, not how many services you should have.

✅ Example

Even in a microservice like OrderService, you can still break SRP:

class OrderService {
    void createOrder(...) { ... }
    void sendConfirmationEmail(...) { ... }
    void updateInventory(...) { ... }
}

This service may be “small” and “independent,” but the class itself handles too many responsibilities.

The SRP-compliant version would delegate:

OrderProcessor → handles core business logic
InventoryUpdater → manages stock
NotificationService → sends emails

SRP helps you organize code within microservices, not decide how many services to build.

Conclusion

The Single Responsibility Principle helps you write Java code that is easier to change, easier to test, and easier to understand.

In the real world, SRP is less about counting methods and more about clarifying responsibilities. When applied well, it becomes a foundation for clean, robust architecture.

You can find the complete code of this article here in GitHub.

📚 Related: Open/Closed Principle in Java

Originally published on my blog: https://nkamphoa.com/single-responsibility-principle-in-java/

How to Mock Static Methods With Mockito

Noel KAMPHOA — Wed, 14 May 2025 09:05:22 +0000

Introduction

Have you ever gotten stuck writing automated tests for a class because it was using static method calls? Although the best practice is to refactor the code so that it no longer uses static methods, in some cases this isn't possible. This is the case, for example, if the code in question does not belong to you. The Path and Files classes in the java.nio package are practical examples. In this article, you will learn how to mock static methods using the Mockito library.

The Application Under Test

The application we are going to test has three main classes:

SalesProcessorStatic.java: This class has a unique method compute that takes a list of strings representing the content of a CSV file. The String has the following structure "productCode;saleAmount". The compute() method must return the total sales of the input List.
SaleLineParser: This class takes a string in the form "productCode;saleAmount", parses it, and returns a Sale object.
Sale.java: is a simple Java record with two fields: public record Sale(String productCode, int saleAmount) { }

The SalesProcessorStatic.java class

package com.kbytes;

import java.util.List;
import java.util.function.Function;

public class SalesProcessorStatic {

    public SalesProcessorStatic(){
    }

    public int compute(List<String> sales){
        Function<String,Sale> toSale = SaleLineParserStatic::parse;
        return sales.stream()
                .map(toSale)
                .map(Sale::saleAmount)
                .reduce(Integer::sum).orElse(0);
    }
}

The Class to be Mocked: SaleLineParserStatic.java

package com.kbytes;

public class SaleLineParserStatic {
    private static final int COLUMN_COUNT = 2;

    public static Sale parse(String line){
        return parse(line,";");
    }
    public static Sale parse(String line, String delimiter){
        String[] saleData = line.split(delimiter,-1);

        if(isInvalidColumnCount(saleData))
            throw new IllegalArgumentException("The file must have "+COLUMN_COUNT+" columns!");

        if(isInvalidField(saleData))
            throw new IllegalArgumentException("The file data format is invalid!");

        return new Sale(saleData[0],Integer.parseInt(saleData[1]));
    }

    private static boolean isInvalidField(String[] saleData) {
        boolean isSaleInvalid = true;
        try{
            Double.parseDouble(saleData[1]);
            isSaleInvalid = false;
        }catch (NumberFormatException ex){
            ex.printStackTrace();
        }
        return saleData[0] == null || saleData[0].isEmpty() || isSaleInvalid;
    }

    private static boolean isInvalidColumnCount(String[] saleData) {
        return saleData != null && (saleData.length != COLUMN_COUNT);
    }
}

The Sale.java Record

public record Sale(String productCode, int saleAmount) { }

As you can see from this line Function<String,Sale> toSale = SaleLineParserStatic::parse, the compute() method of the SalesProcessorStatic class is making a static call to the parse() method of SaleLineParserStatic. To test the SaleProcessorStatic class independently of the SaleLineParserStatic, you have to mock the call to the static method SaleLineParserStatic.parse().

Step 1: Add the Maven Dependency

The only dependencies that you will need are JUnit 5 Engine and Mockito Core.

Add the following dependencies to your project:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.9.2</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>5.11.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Step 2: Mock The Static Method with `MockedStatic`

Mocking static methods has been possible since Mockito 3.4.0. The procedure for mocking a static method is as follows:

Use the mockStatic() method of the Mockito class: mockStatic(SaleLineParserStatic.class)
Retrieve the object returned by the mockStatic() method in a variable of type MockedStatic: MockedStatic<SaleLineParserStatic> mockSaleLineParser = mockStatic(SaleLineParserStatic.class)
Configure the mock object: mockSaleLineParser.when(() -> SaleLineParserStatic.parse("P1;10")).thenReturn(sale1)

From the MockedStatic class Javadoc, you can read the following:

The static mock is released when this object's MockedStatic#close() method is invoked. If this object is never closed, the static mock will remain active on the initiating thread. It is therefore recommended to create this object within a try-with-resources.

Below is the complete test method for the SalesProcessorStatic class:

    @Test
void test_simple_compute(){
    //given
    List<String> sales = List.of("P1;10","P2;20");
    Sale sale1 = new Sale("P1",50);
    Sale sale2 = new Sale("P2",70);
    int expectedTotal = 120;
    try(MockedStatic<SaleLineParserStatic> mockSaleLineParser = mockStatic(SaleLineParserStatic.class)){
        mockSaleLineParser.when(() -> SaleLineParserStatic.parse("P1;10")).thenReturn(sale1);
        mockSaleLineParser.when(() -> SaleLineParserStatic.parse("P2;20")).thenReturn(sale2);
        //when
        SalesProcessorStatic salesProcessor = new SalesProcessorStatic();
        int salesTotal = salesProcessor.compute(sales);
        //then
        Assertions.assertEquals(expectedTotal,salesTotal);
    }
}

Given that the mock object is closed at the end of the try-with-resource block, the verifying part (Assertions) of your test must be within that same block.

If you need to mock different classes in the same test, you should add them to the try-with-resource block like this:

    try(MockedStatic<FirstClassWithStaticMethod> firstMock = mockStatic(FirstClassWithStaticMethod.class);
MockedStatic<SecondClassWithStaticMethod> secondMock = mockStatic(SecondClassWithStaticMethod.class)){
        //your code  
        }

Conclusion

In this quick tutorial, you learned how to mock static methods using Mockito. If you want to learn how to use this approach to mock access to the FileSystem, check out this article.

The full code of this tutorial can be found here on GitHub.

Originally published on my blog: https://nkamphoa.com/how-to-mock-static-methods-with-mockito/

DEV Community: Noel KAMPHOA

Centralized Logging for Java Apps With ELK and Docker Compose

1. Introduction

2. Prerequisites

3. Directory Structure

4. Configuration files

4.1. Elasticsearch

4.2. Logstash

4.3. Kibana

5. The docker-compose file

5.1. Elasticsearch Service

5.2. Logstash Service

5.3. Kibana Service

6. Start the Services

7. Verify the installation

8. Shipping Your Java Application Logs

8.1. For our Spring Boot REST Application using Logback:

Create or edit your logback-spring.xml

Restart your Java application.

View the Logs in Kibana

9. Conclusion

Exception Hierarchy in Java: Checked, Unchecked, and Errors

Introduction

1. Root of the Hierarchy: Throwable

2. Errors in Java

3. Checked Exceptions

4. Unchecked Exceptions

5. Custom Exceptions

6. Summary of Exception Hierarchy

Conclusion

Understand the Factory Method Pattern in Java

1. Introduction

2. What Is the Factory Method Pattern?

Key Characteristics

3. Core Components

4. Example Implementation

Client Code

5. Advantages of the Factory Method Pattern

6. Use Cases in Real Projects

7. Conclusion

Abstract Classes and Interfaces in Java

Introduction

1. What is an Interface?

2. What is an Abstract Class?

3. Key Differences

4. When to Use What

5. Real-World Example: Notification System

Option 1: Interface

Option 2: Abstract class

Conclusion

Single Responsibility Principle in Java

Introduction

1. A Real-World Example: User Registration

2. Identifying the Responsibilities

3. Refactoring for SRP

✅ Extract validation:

✅ Extract password logic:

✅ Extract email logic:

🔁 Updated UserService:

4. When Is SRP Worth It?

4.5. SRP vs. Microservices: A Note

✅ Example

Conclusion

How to Mock Static Methods With Mockito

Introduction

The Application Under Test

The SalesProcessorStatic.java class

The Class to be Mocked: SaleLineParserStatic.java

The Sale.java Record

Step 1: Add the Maven Dependency

Step 2: Mock The Static Method with MockedStatic

Conclusion

🔁 Updated `UserService`:

Step 2: Mock The Static Method with `MockedStatic`