Forem: Eduardo

Minimal Guide to Resilience4j and Circuit Breaker in Spring Boot

Eduardo — Tue, 30 Dec 2025 18:25:14 +0000

Resilience4j is a library designed to guarantee application availability, mainly in high-load environments. With the rise of Microservices, it has become essential to control what happens when one of our services fails or is slow to respond, preventing a "cascading failure."

What is a Circuit Breaker?

The Circuit Breaker pattern works similarly to electrical breakers in a house. If it detects a failure, it "opens" the circuit to prevent further damage and "closes" it once the problem is resolved.

A Circuit Breaker has three main states:

Closed: Everything is working correctly. Requests flow normally.
Open: Failures have exceeded the allowed threshold. Requests are blocked and a fallback is executed.
Half-Open: A trial period where a limited number of requests are allowed to check if the service has recovered.

1. Resilience4j Configuration

To start, we create a Spring Boot project and add the following dependency:

<dependency>
   <groupId>io.github.resilience4j</groupId>
   <artifactId>resilience4j-spring-boot2</artifactId>
</dependency>

In our application.yml, we define the parameters that will govern the behavior of our Circuit Breaker:

resilience4j:
  circuitbreaker:
    instances:
      mainService:
        registerHealthIndicator: true
        slidingWindowSize: 10
        permittedNumberOfCallsInHalfOpenState: 3
        slidingWindowType: COUNT_BASED
        minimumNumberOfCalls: 5
        waitDurationInOpenState: 10s
        failureRateThreshold: 50
        eventConsumerBufferSize: 10

Parameter Breakdown:

slidingWindowSize: The number of calls to record when the circuit is closed.
failureRateThreshold: The percentage of failures (e.g., 50%) at which the circuit should open.
waitDurationInOpenState: How long the circuit stays "Open" before trying to recover.
permittedNumberOfCallsInHalfOpenState: Number of successful calls needed in "Half-Open" to close the circuit again .

2. Implementation with Annotations

The easiest way to use it is by using the @CircuitBreaker annotation. We must specify the name of the instance we configured in the YAML and a fallback method.

Note: The fallback method must have the same signature as the original method, but it must also receive a Throwable or Exception as an argument.

2. Implementation with Annotations

The easiest way to use it is by using the @CircuitBreaker annotation. We must specify the name of the instance we configured in the YAML and a fallback method.

Note: The fallback method must have the same signature as the original method, but it must also receive a Throwable or Exception as an argument.

@Service
public class ProductService {

    @CircuitBreaker(name = "mainService", fallbackMethod = "fallbackGetProducts")
    public List<Product> getProducts() {
        // Logic that might fail (e.g., calling an external API)
        return externalApi.fetchProducts();
    }

    // Fallback Method
    public List<Product> fallbackGetProducts(Throwable e) {
        return List.of(new Product("Default Product", 0.0));
    }
}

3. Other Resilience4j Modules

While the Circuit Breaker is the most famous, Resilience4j offers other tools to improve stability:

TimeLimiter
Used to set a maximum execution time for a request. If the service doesn't respond within the timeframe, it triggers a failure.

Retry
Allows us to automatically retry a failed operation a specific number of times before giving up.

Bulkhead
Limits the number of concurrent calls to a service to avoid saturating resources (like thread pools).

Conclusions

Resilience4j is a powerful tool for building robust Microservices. By implementing the Circuit Breaker pattern, we ensure that our application can fail gracefully instead of crashing completely under pressure.

Spring Cloud Gateway: Basic Example

Eduardo — Tue, 30 Dec 2025 18:03:07 +0000

Spring Cloud Gateway (also known as a gateway or Edge Service) is a dynamic routing server. In other words, it allows us to have a centralized access point to our Microservices. Additionally, we can extend its functionality by adding filters or predicates, among other things.

1. Spring Cloud Gateway Configuration

We create a project using Spring Initializr or our favorite IDE, making sure to select the following dependencies:

Eureka Discovery Client
Gateway

This project will also be registered by Eureka Server, so we add the following configuration:

@EnableEurekaClient
@SpringBootApplication
public class EurekaClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaClientApplication.class, args);
    }
}

Now we configure the application name and the port where it will be deployed. We can do this in a properties or yml file.

spring:
  application:
    name: gateway-server-service
server:
  port: 8090
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka

Just like the previous configuration, Spring Cloud Gateway can be configured in a properties file or a yml file, but for easier reading, I will show the yml configuration here.

2. Routes

The minimum essential configuration for the Edge or Gateway is the routes. These routes will redirect requests from the Gateway to the service that will answer the request.

The following is an example of a basic route configuration in YAML:

spring:
  cloud:
    gateway:
      routes:
        - id: employees
          uri: lb://employees
          predicates:
            - Path=/api/employees/**
          filters:
            - StripPrefix=2

id: Unique identifier of the route.
uri: Address where the Edge will look for the service to redirect. It must start with lb (Load Balancer) if using service discovery like Eureka.
predicates: Series of rules that must be met for the redirection.
filters: Help us work with the request and response passing through the declared route.

In the case of the example, it is routing to a Microservice called employees (or empleados), and if we want to get a response from it, we can use the Spring Cloud Gateway pointing to the Edge port and not to the Microservice Port directly.

2.1 Predicates

Predicates are a list of rules that must be met for the redirection to the service to be successful.

Predicates can be of various types: by redirection address, by header, by method type, query, or cookie.

List of possible examples:

predicates:
  - Path=/api/products/**
  - Header=token, \d+
  - Method=GET, POST
  - Query=color
  - Cookie=color, blue

Meaning of the predicates:

Path: Allows redirection of requests that match the declared path.
Header: Checks that the declared header comes within the request with the indicated value (regex capable).
Method: Indicates that it only receives the declared HTTP methods.
Query: Indicates that the search parameter must appear in the URL query.
Cookie: Checks that the indicated cookie is present.

2.2 Spring Cloud Gateway Factory Filters

There are filters that help us manipulate the request and response. This means you can add information to the request or response within the headers or as a parameter in the request.

The way to add it is in the application.yml file within the configuration section of the desired path in a comma-separated key-value format.

filters:
  - AddRequestHeader=token-request, 123456
  - AddResponseHeader=token-response, 12345678
  - SetResponseHeader=Content-Type, text/plain
  - AddRequestParameter=name, andres

2.3 Spring Cloud Gateway Global Filters

There is a way to make a filter pass through all our requests and responses without having to declare it one by one. In the following example, we are going to add a header to the request and a cookie to the response of all requests that pass through the Spring Cloud Gateway.

package com.funcionaenmimaquina.springboot.app.gateway.filters;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.http.MediaType;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

import java.util.Optional;

@Component
public class ExampleGlobalFilter implements GlobalFilter, Ordered {

    private final Logger logger = LoggerFactory.getLogger(ExampleGlobalFilter.class);

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        logger.info("Executing request filter");

        // Modifying the request
        exchange.getRequest().mutate().headers(h -> h.add("environment", "dev"));

        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            logger.info("Executing response filter");

            // Modifying the response
            Optional.ofNullable(exchange.getRequest().getHeaders().getFirst("environment")).ifPresent(value -> {
                exchange.getResponse().getHeaders().add("env", value);
            });

            exchange.getResponse().getHeaders().setContentType(MediaType.TEXT_PLAIN);
        }));
    }

    @Override
    public int getOrder() {
        return 1;
    }
}

To understand the previous example, we must highlight several things:

It implements the GlobalFilter and Ordered interfaces.
The overridden method getOrder is used to give an order in case of having more global filter classes.
In the overridden filter method, all the logic to interact with our request and response is written.
Line 24 shows the section where you can manipulate the request, in this case adding a header.
Line 27 shows how to manipulate a response (using .then(Mono.fromRunnable(...))).
Line 31 adds a header to the response if the condition that a specific header exists is met.
Line 34 manipulates the response to take a plain text format.

2.4 Filter Factory (Custom Gateway Filter)

If we do not want the Filter to pass through all requests and responses, but only through those we specify, we can create a custom filter as follows.

@Component
public class ExampleGatewayFilterFactory extends AbstractGatewayFilterFactory<ExampleGatewayFilterFactory.Config> {

    private final Logger logger = LoggerFactory.getLogger(ExampleGatewayFilterFactory.class);

    public ExampleGatewayFilterFactory() {
        super(Config.class);
    }

    @Override
    public GatewayFilter apply(Config config) {
        return (exchange, chain) -> {
            logger.info("Zone to modify the request");

            return chain.filter(exchange).then(Mono.fromRunnable(() -> {
                logger.info("Zone to modify the response");

                Optional.ofNullable(config.cookieValue).ifPresent(cookieVal -> {
                    exchange.getResponse().addCookie(ResponseCookie.from(config.cookieName, cookieVal).build());
                });
            }));
        };
    }

    @Override
    public String name() {
        return "ExampleCookie";
    }

    @Override
    public List<String> shortcutFieldOrder() {
        return Arrays.asList("cookieName", "cookieValue");
    }

    public static class Config {
        private String cookieName;
        private String cookieValue;

        // Getters and Setters
        public String getCookieValue() { return cookieValue; }
        public void setCookieValue(String cookieValue) { this.cookieValue = cookieValue; }
        public String getCookieName() { return cookieName; }
        public void setCookieName(String cookieName) { this.cookieName = cookieName; }
    }
}

Usage in YML:

filters:
  - StripPrefix=2
  - ExampleCookie=user, myName

What the code above does is add a Cookie to the response of the request with the values described in the yml file, and the following should be highlighted:

By convention, the class name must end in FilterFactory.

It extends the AbstractGatewayFilterFactory class.

You need to use a configuration class (inner class Config); this configuration class will store the values sent from the yml file.

The functionality is coded inside the apply method.

The return value of the name() method must match the key in the yml file (or default to the class name prefix).

The shortcutFieldOrder method indicates the order in which the values will be assigned from the YAML short notation.

Now this filter will only be applied to the requests configured within the application.yml file.

Conclusions

Now you know what Spring Cloud Gateway is for and what you can achieve by configuring it. You know how to configure predicates and filters to extend its functionality. Don't forget to practice to be able to use it in the professional world.

How to Configure Eureka Server

Eduardo — Tue, 30 Dec 2025 17:30:04 +0000

The goal of Eureka Server is to locate and register services you want to interact with. Additionally, it helps with load balancing and fault tolerance.

To configure Eureka Server, there must be at least two types of applications: one application acting as the server and another as the client.

Each service must communicate with the Eureka Server to tell it that it is available for use. Eureka Server will store its information and status. This communication between the microservice and Eureka is called heartbeats and occurs every 30 seconds. If 3 heartbeats fail, Eureka Server removes it from the list.

1. Configure the Eureka Server Project

To create the project, we can use the Spring Boot Initializr tool or the wizard in your preferred IDE. For this example, Spring Boot version 2.7.0 will be used.

During project creation, we must ensure we select "Eureka Server" (usually listed as Eureka Server in Initializr) so that our project has the necessary libraries to perform the example.

Once the project is created, we must configure our properties file (application.yml) as follows:

eureka:
  client:
    fetch-registry: false
    register-with-eureka: false
spring:
  application:
    name: servicio-eureka-server
server:
  port: 8761

The configuration inside the eureka node prevents the Eureka Server application from registering itself. The spring node gives the name to the application we are working on, and the server node indicates the port on which the application will run. By convention, Eureka Server is assigned this port number (8761).

Finally, we must add the @EnableEurekaServer annotation to our class containing the main method.

@EnableEurekaServer
@SpringBootApplication
public class SpringBootEurekaServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(SpringBootEurekaServerApplication.class, args);
    }
}

To test the application, we run it and go to http://localhost:8761, where we can observe the Eureka Server dashboard.

2. Configuration of a Eureka Client

To create the application that will connect to Eureka Server, we follow a similar process to the previous one using Spring Boot Initializr or our preferred IDE. However, now we must ensure we select "Eureka Discovery Client" so that it can be correctly registered in Eureka Server.

Now we configure the application.yml of the Eureka Client as follows:

spring:
  application:
    name: eureka-client
server:
  port: ${PORT:0}
eureka:
  instance:
    instance-id: ${spring.application.name}:${spring.application.instance_id:${random.value}}

As we saw earlier, the spring.application.name node gives the application its name. server.port indicates the communication port where the application will start; in this case, we are not setting a specific port but leaving it dynamic (${PORT:0}).

Now, the instance-id node is necessary to be able to run on a different random port with a different random instance ID. In this case, instance-id is formed by the application name and a random value.

Now we must declare in the main method that this is a Eureka Client:

@EnableEurekaClient
@SpringBootApplication
public class EurekaClientApplication {

    public static void main(String[] args) {
        SpringApplication.run(EurekaClientApplication.class, args);
    }
}

To verify that Eureka Server registers the services correctly, we first start Eureka Server, and then we can start the Eureka Client application twice to verify that the ports do not clash and that the port number and instance ID are random.

Now we go to http://localhost:8761 to verify this. We can notice that the ports did not clash, they each have a different random ID, and they are correctly registered in Eureka Server.

3. How to Consume a Eureka Client Service

Now we are going to build a service that makes a request to our service called Eureka Client. To do this, we are going to modify our Eureka Client service slightly by adding a Rest Controller, and we will create a new service that functions as a Rest client.

Rest Controller in Eureka Client
Inside the Eureka Client Project, we are first going to create a POJO Object that will be returned to be visualized as a result.

public class Item implements Serializable {
    private static final long serialVersionUID = 129348938L;
    private int i;
    private String name;

    public Item() {
    }

    public Item(int i, String name) {
        this.i = i;
        this.name = name;
    }

    // Getters, Setters, Equals and HashCode
    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    // ... equals and hashCode methods
}

Then we create some dummy business logic where we obtain a list of Item objects.

public interface ItemService {
    List<Item> findAll();
}

@Service
public class ItemServiceImpl implements ItemService {
    @Override
    public List<Item> findAll() {
        List<Item> items = new ArrayList<>();
        Item item;
        for(int i = 0 ; i < 10; i++){
            item = new Item(i, "Item " + i);
            items.add(item);
        }
        return items;
    }
}

And we link it with the controller.

@RestController
public class ItemController {

    private static Logger logger = LoggerFactory.getLogger(ItemController.class);

    @Autowired
    private ItemService itemService;

    @GetMapping(path = "/listing", produces = MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<List<Item>> listing(){
        List<Item> all = itemService.findAll();
        return new ResponseEntity<>(all, HttpStatus.OK);
    }
}

4. Spring Boot Feign Client

Now we are going to create a new project that will serve as a client for our Microservice using Feign.

First, we create an object representing Item in this project as well (similar to the code above).

Now we create the Feign client. In the name property, we put the name of the service exactly as we registered it in Eureka Server.

You might notice that no URL or port is configured within this connection. This is thanks to Eureka and the fact that we configured a random port in the Eureka Client. Now we can spin up N number of services with random ports and everything will work transparently.

@FeignClient(name = "eureka-client")
public interface ProductRestClient {

    @GetMapping(path = "/listing")
    public List<ItemDto> list();
}

public interface ItemService {
    public List<ItemDto> findAll();
}

@Service
public class ItemServiceFeign implements ItemService {

    @Autowired
    private ProductRestClient feignClient; // Feign Client

    @Override
    public List<ItemDto> findAll() {
        return feignClient.list();
    }
}

We create the Controller for the Feign client and configure the project properties.

@RestController
public class ItemController {

    @Autowired
    private ItemService itemService;

    @GetMapping(path = "/list")
    public List<ItemDto> list(){
        return itemService.findAll();
    }
}

spring:
  application:
    name: feign-client
server:
  port: 8002

Our example is now ready to be tested. Using any browser, we can go to the URL http://localhost:8002/list and we will get the JSON result.

Conclusions

In this post, we were able to see how Eureka helps us scale our services, and makes communication between them easier. We created an example to observe how it behaves and how simple it is to configure Eureka Server. Now we can use it for our projects or to create our portfolio.

Relevant Links

Post in spanish

Builder Pattern in Java: Clear Examples and Real Application

Eduardo — Tue, 30 Dec 2025 17:02:49 +0000

The Builder design pattern in Java is a creational design pattern. It allows you to separate the construction of an object from its representation. In other words, it enables the creation of an object step-by-step. This is especially useful for complex objects.

When should you use the Builder pattern?

Imagine we have an object with 8 attributes. To create it, we need to write a constructor with 8 arguments. But what if we don't want to use all 8 attributes? Since passing null as a parameter is a bad practice, should we create a constructor for 7 arguments, and one for each possible combination of parameters?

For these cases, we can apply the Builder design pattern in Java.

What are the advantages of using the Builder pattern?

Flexibility: It allows the creation of objects with the desired number of parameters in a natural way.

Readability: The implementation of this pattern is easy to follow and understand.

Immutability: It is possible to enforce immutability once the object has finished being built, thus guaranteeing thread safety against unwanted modifications.

How is the Builder pattern implemented in Java?

Since design patterns are abstract solutions to recurring problems, we can adapt our implementations according to the context we are in. For this reason, here are several examples of how to implement the Builder design pattern in Java.

1. Classic Builder Design Pattern in Java

This is the classic way to create the Builder design pattern in Java.

The first thing to notice is the private final attributes of our object, the getter methods, and the omission of setter methods. This makes the values immutable.

Next, we see the static Builder class which repeats the same fields as the main Product class, and each attribute has a method to set information. We can see the constructor that only receives the builder object. Finally, we see the build method that returns an object of type Product.

package com.funcionaenmimaquina.builder.classic;

public class Product {
    private final String name;
    private final String description;
    private final double price;
    private final String category;
    private final String imageUrl;
    private final String brand;
    private final String sku;

    private Product(Builder builder) {
        this.name = builder.name;
        this.description = builder.description;
        this.price = builder.price;
        this.category = builder.category;
        this.imageUrl = builder.imageUrl;
        this.brand = builder.brand;
        this.sku = builder.sku;
    }

    public static class Builder {
        private String name;
        private String description;
        private double price;
        private String category;
        private String imageUrl;
        private String brand;
        private String sku;

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder description(String description) {
            this.description = description;
            return this;
        }

        public Builder price(double price) {
            this.price = price;
            return this;
        }

        public Builder category(String category) {
            this.category = category;
            return this;
        }

        public Builder imageUrl(String imageUrl) {
            this.imageUrl = imageUrl;
            return this;
        }

        public Builder brand(String brand) {
            this.brand = brand;
            return this;
        }

        public Builder sku(String sku) {
            this.sku = sku;
            return this;
        }

        public Product build() {
            return new Product(this);
        }
    }

    @Override
    public String toString() {
        return "Product{" +
                "name='" + name + '\'' +
                ", description='" + description + '\'' +
                ", price=" + price +
                ", category='" + category + '\'' +
                ", imageUrl='" + imageUrl + '\'' +
                ", brand='" + brand + '\'' +
                ", sku='" + sku + '\'' +
                '}';
    }

    // Getters...
    public String getName() { return name; }
    public String getDescription() { return description; }
    public double getPrice() { return price; }
    public String getCategory() { return category; }
    public String getImageUrl() { return imageUrl; }
    public String getBrand() { return brand; }
    public String getSku() { return sku; }
}

Now we can use the Java builder in the following way. We create an object of type Product.Builder, which allows us to access the methods for assigning attribute values, and finally, we call the build method to finish constructing our object.

static void runClassicBuilder() {
    System.out.println("Classic Builder Pattern Example");
    Product product = new Product.Builder()
            .name("Laptop")
            .description("High performance laptop")
            .price(1200.00)
            .category("Electronics")
            .imageUrl("http://example.com/laptop.jpg")
            .brand("BrandX")
            .sku("SKU12345")
            .build();
    System.out.println(product.toString());
}

2. Generic Builder Design Pattern with Lambdas

Thanks to lambdas, we can create a generic builder to use with all our objects.

import java.util.function.BiConsumer;
import java.util.function.Supplier;

public class Builder<T> {
    private final Supplier<T> supplier;

    private Builder(Supplier<T> supplier) {
        this.supplier = supplier;
    }

    public static <T> Builder<T> of(Supplier<T> supplier) {
        return new Builder<>(supplier);
    }

    public <P> Builder<T> with(BiConsumer<T, P> consumer, P value) {
        return new Builder<>(() -> {
            T object = supplier.get();
            consumer.accept(object, value);
            return object;
        });
    }

    public T build() {
        return supplier.get();
    }
}

Let's use a User class for this example:

public class User {
    private String name;
    private String lastname;
    private String secondLastName;
    private String phone;
    private String email;

    // Getters and Setters needed
    public void setName(String name) { this.name = name; }
    public void setLastname(String lastname) { this.lastname = lastname; }
    public void setSecondLastName(String secondLastName) { this.secondLastName = secondLastName; }
    public void setPhone(String phone) { this.phone = phone; }
    public void setEmail(String email) { this.email = email; }

    @Override
    public String toString() {
        return "User{" +
                "name='" + name + '\'' +
                ", lastname='" + lastname + '\'' +
                ", secondLastName='" + secondLastName + '\'' +
                ", phone='" + phone + '\'' +
                ", email='" + email + '\'' +
                '}';
    }
}

This generic builder uses the of() method to assign the data type and the with() method to assign the value to the object's attribute. The usage of this builder looks elegant and friendly to read. It provides flexibility, but since it relies on the object's setters, it leaves immutability aside.

static void runGenericBuilder() {
    System.out.println("Generic Builder Pattern Example");
    User user = Builder.of(User::new)
            .with(User::setName, "John")
            .with(User::setLastname, "Doeh")
            .with(User::setSecondLastName, "Doeh")
            .with(User::setPhone, "555555")
            .with(User::setEmail, "mail@mail.com")
            .build();
    System.out.println(user.toString());
}

3. Builder Design Pattern in Java with Lombok

Lombok is a Java library that helps us eliminate boilerplate code through annotations. Among its many functions, it gives us a way to implement the Builder design pattern simply.

import lombok.Builder;
import lombok.Getter;
import lombok.ToString;

@Builder
@Getter
@ToString
public class Videogame {
    private String name;
    private String platform;
    private String category;
}

Usage:

static void runLombokBuilder() {
    System.out.println("Lombok Builder Pattern Example");
    Videogame videogame = Videogame.builder()
            .name("The Legend of Zelda")
            .platform("Nintendo Switch")
            .category("Action-Adventure")
            .build();
    System.out.println(videogame.toString());
}

We can also use the @builder annotation on Records.

@Builder
public record SoccerTeam(String name, String country, String coach) {
}

4. Builder Design Pattern using Records in Java

Records arrived in Java with the mission of creating immutable classes without boilerplate code. If we want to use the Builder design pattern in Java with Records (without Lombok), we can do it as follows:

public record Smartphone(String model, String brand, String operatingSystem, double price) {

    public static Builder builder() {
        return new Builder();
    }

    public static class Builder {
        private String model;
        private String brand;
        private String operatingSystem;
        private double price;

        public Builder model(String model) {
            this.model = model;
            return this;
        }

        public Builder brand(String brand) {
            this.brand = brand;
            return this;
        }

        public Builder operatingSystem(String operatingSystem) {
            this.operatingSystem = operatingSystem;
            return this;
        }

        public Builder price(double price) {
            this.price = price;
            return this;
        }

        public Smartphone build() {
            return new Smartphone(model, brand, operatingSystem, price);
        }
    }
}

In the code above, we can observe the build method inside the Builder class that creates the object, and the static builder() method in the Record that returns the Builder object so we can access the value assignment methods.

static void runRecordBuilder() {
    System.out.println("Record Builder Pattern Example");
    Smartphone smartphone = Smartphone.builder()
            .model("iPhone 14")
            .brand("Apple")
            .operatingSystem("iOS")
            .price(999.99)
            .build();
    System.out.println(smartphone.toString());
}

Conclusion

Now we know what the Builder design pattern is for and we have seen that there are several ways to implement it. It is important to know the context of our project to know which one best adapts to our needs.

Relevant Links

@ConditionalOnProperty In Spring Boot

Eduardo — Tue, 03 Jun 2025 16:06:39 +0000

Sometimes we need to create different types of beans depending on certain conditions. Let's suppose we have a system in which we send notifications, and some clients of that system prefer notifications via email, while others prefer SMS notifications. In this case, we would need to inject a different bean for each client. To solve this problem, we can use the @ConditionalOnProperty annotation in Spring Boot.

What is @ConditionalOnProperty In Spring Boot?

@ConditionalOnProperty can read Spring Boot properties and, based on their values, determine whether the Bean will be created or not. This can be useful for solving the problem presented in the previous paragraph, or, for example, if we want to use a different Bean for the dev and prod environments.

How does @ConditionalOnProperty work in Spring Boot?

The operation of the annotation is quite intuitive:

@ConditionalOnProperty(name = "someName", havingValue = "true")

In the “name” attribute we put the property on whose value the creation of the Bean will depend and the “havingValue” attribute determines the expected value to create the Bean or not.

Example of using @ConditionalOnProperty in Spring Boot

The first thing we need to do is create a property in the application yml file.

configuration:
  smsMessageEnabled: true

Now we can create an Interface and two classes that inherit from this interface.

@Service
@ConditionalOnProperty(name = "configuration.emailMessageEnabled", havingValue = "true")
public class EmailMessageServiceImpl implements MessageService{

    private static final Logger log = LoggerFactory.getLogger(EmailMessageServiceImpl.class);

    @Override
    public void sendMessage(String message) {
       log.info("Sending Email message: {}",message);
    }

}

public interface MessageService {
    void sendMessage(String message);
}

@Service
@ConditionalOnProperty(name = "configuration.smsMessageEnabled", havingValue = "true")
public class SmsMessageServiceImpl implements MessageService{

    private static final Logger log = LoggerFactory.getLogger(SmsMessageServiceImpl.class);

    @Override
    public void sendMessage(String message) {
        log.info("Sending SMS message: {}",message);
    }

}

In the previous code we can see how we implemented the sendMessage method only with a log just for the purposes of the @ConditionalOnProperty example; in a real case this could be a call to some API.

In the @ConditionalOnProperty annotation we can see the reference to the property name that we wrote in the application yml file.

Now we have to test the code:

@SpringBootApplication
public class ConditionalOnProperty {

  private static final Logger logger = LoggerFactory.getLogger(ConditionalOnProperty.class);

  @Autowired
  MessageService messageService;

  public static void main(String[] args) {
    SpringApplication.run(ConditionalOnProperty.class, args);

  }

  @EventListener(ApplicationReadyEvent.class)
  public void onApplicationReady() {
    logger.info("Start");
    messageService.sendMessage("Any Text ");
    logger.info("Finish");
  }

}

We will get an output like this:

We can see that we got the call of the method of the SmsMessageServiceImpl class which was the one we configured in the application.yml file

What did we learn?

Now we know that @ConditionalOnProperty helps us create beans based on defined conditions. Using it allows us to adapt our code to different environments, giving us greater flexibility in our application's behavior.

Forem: Eduardo

Minimal Guide to Resilience4j and Circuit Breaker in Spring Boot

What is a Circuit Breaker?

1. Resilience4j Configuration

2. Implementation with Annotations

2. Implementation with Annotations

3. Other Resilience4j Modules

Conclusions

Related Links

Spring Cloud Gateway: Basic Example

1. Spring Cloud Gateway Configuration

2. Routes

2.1 Predicates

2.2 Spring Cloud Gateway Factory Filters

2.3 Spring Cloud Gateway Global Filters

2.4 Filter Factory (Custom Gateway Filter)

Conclusions

Related Links

How to Configure Eureka Server

1. Configure the Eureka Server Project

2. Configuration of a Eureka Client

3. How to Consume a Eureka Client Service

4. Spring Boot Feign Client

Conclusions

Relevant Links

Builder Pattern in Java: Clear Examples and Real Application

When should you use the Builder pattern?

What are the advantages of using the Builder pattern?

How is the Builder pattern implemented in Java?

1. Classic Builder Design Pattern in Java

2. Generic Builder Design Pattern with Lambdas

3. Builder Design Pattern in Java with Lombok

4. Builder Design Pattern using Records in Java

Conclusion

Relevant Links

@ConditionalOnProperty In Spring Boot

What is @ConditionalOnProperty In Spring Boot?

How does @ConditionalOnProperty work in Spring Boot?

What did we learn?