DEV Community: Adam Tarcali

Feign Clients with Multiple Interceptors in Spring Boot

Adam Tarcali — Wed, 18 Jun 2025 09:02:13 +0000

When working with Spring Boot and OpenFeign, it's quite common to add custom headers to outbound HTTP requests — like tracking IDs, authentication tokens, or metadata provided by libraries. But what happens when you want to add multiple interceptors in a clean, reusable, and testable way?

This blog post shows you how to chain multiple Feign RequestInterceptor instances using a composite pattern. You'll learn how to centralize header management, avoid duplication, and write integration tests to verify everything works as expected.

Step 1: Define a Feign Client

Let's start with a basic Feign client interface:

@FeignClient(
    name = "fooClient",
    url = "${foo.base-url}",
    configuration = FeignConfig.class
)
public interface FooClient {
    @GetMapping("/api/internal/foo")
    String callInternalFoo();
}

In application.yml, we define the base URL:

foo:
  base-url: ${FOO_BASE_URL:http://localhost:8080}

⚠️ Important: If you're calling your own application (localhost), be careful not to create a circular call like /foo → Feign → /internal/foo → Feign → ... This can cause a stack overflow or exhaust your thread pool. Ideally, use a mock server or a different port/environment for internal calls.

Step 2: The Magic — Composite Interceptor

Here's the core idea: one interceptor that delegates to multiple others.

public class CompositeRequestInterceptor implements RequestInterceptor {

    private final List<RequestInterceptor> interceptors;

    public CompositeRequestInterceptor(RequestInterceptor... interceptors) {
        this.interceptors = Arrays.stream(interceptors).toList();
    }

    @Override
    public void apply(RequestTemplate template) {
        for (RequestInterceptor interceptor : interceptors) {
            interceptor.apply(template);
        }
    }
}

Step 3: Define Individual Interceptors

You can create small, focused interceptors for each concern — even put them into separate modules/libraries.

public class TrackingIdInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        template.header("X-Tracking-ID", UUID.randomUUID().toString());
    }
}

public class AuthTokenInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        template.header("X-Auth-Token", "mockedTokenValue");
    }
}

public class LibraryProvidedInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        template.header("X-Library", "libValue");
    }
}

Step 4: Configure the Feign Client

Now we plug everything together in a configuration class:

@Configuration
public class FeignConfig {

    @Bean
    public RequestInterceptor compositeInterceptor() {
        return new CompositeRequestInterceptor(
            new AuthTokenInterceptor(),
            new TrackingIdInterceptor(),
            new LibraryProvidedInterceptor()
        );
    }
}

💡 Pro tip: Avoid mixing @Component and @Bean registration for interceptors. Pick one method to avoid registering the same interceptor multiple times.

Step 5: Enable Feign Clients

Make sure your application is configured to scan for Feign clients:

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

✅ Result — Interceptors Are Applied

When your application makes a call via the FooClient, all configured interceptors will be applied and headers added to the request. For example:

X-Auth-Token: [mockedTokenValue]
X-Library: [libValue]
X-Tracking-ID: [4dfd7515-b73b-4a09-bc52-0d4de77d850f]

🧪 Bonus: Verifying Headers with WireMock

You can easily write an integration test using WireMock to verify that all headers are correctly sent.

verify(getRequestedFor(urlEqualTo("/api/internal/foo"))
    .withHeader("X-Auth-Token", equalTo("mockedTokenValue"))
    .withHeader("X-Library", equalTo("libValue"))
    .withHeader("X-Tracking-ID", matchingUuid()));

This ensures that all interceptors are executed as expected.

🙌 Wrap-up

This pattern makes your Feign interceptors more modular, testable, and maintainable. You can add/remove behavior without rewriting configuration logic, and avoid the trap of overcomplicated header management.

Thanks for reading — and if this helped you, feel free to ⭐ the GitHub repo or share the article!

Happy coding!

The IntelliJ Settings I Always Change (Every. Single. Time.)

Adam Tarcali — Tue, 10 Jun 2025 21:43:11 +0000

Whenever I get a new machine, reinstall my system, or start at a new workplace with a freshly installed IntelliJ IDEA, there are a few key settings I always configure right away. They save time, reduce friction, and help me stay focused on writing code instead of fighting the IDE.

1. Auto Import on the Fly

In the past, I used to lose precious minutes manually importing every missing package — especially when pasting code snippets from colleagues or external sources. Enabling “Auto-import on the fly” ensures that IntelliJ automatically takes care of import statements as I write code.

It might seem like a small thing, but over the course of a day (or sprint), it adds up to a lot of saved time and fewer frustrating interruptions.

👉 Settings → Editor → General → Auto Import →Optimize imports on the fly

👉 Settings → Editor → General → Auto Import →Add unambiguous imports on the fly

2. **Optimize ‘Class Count to Use Import with '*'’**

There’s a long-standing debate: should you import individual classes or use wildcard imports when there are too many from the same package? Some teams even enforce thresholds like "only use wildcard if you import more than 5 classes."

To avoid inconsistencies and potential issues during code reviews or merges, I usually set this threshold to a very high number — effectively disabling wildcard imports.

👉 Settings → Editor → Code Style → Java → Imports → Class count to use import with *

👉 Settings → Editor → Code Style → Java → Imports → Names count to use static import with *

3. Compact Mode (Flattened Tree View)

I learned to code on a tiny-screen laptop. With limited screen real estate, navigating long folder trees was a pain.

Enabling Compact Mode (in the Project tool window) tightens up the spacing, making the file tree more readable — especially on smaller screens — without sacrificing clarity.

👉 Settings → Appearance → UI Options →Compact Mode

4. Show Editor Tabs Vertically (on the side)

If you’re like me and tend to keep multiple files open (especially during deep work), you’ve probably seen this:

FooService
FooServiceRepository
FooServiceController

All squeezed into horizontal tabs like this:

FooServ... | FooServ... | FooServ...

Not great. To solve this, I move the editor tabs to the side. That way, I get to see the full class names, can adjust their width, and enjoy slightly more vertical space in the actual code editor.

👉 Settings → Editor → General → Editor Tabs → Tab placement → Right

5. Keep Package Hierarchy Intact (Yes, Really)

I know a lot of folks love “Flatten Packages” for a cleaner, one-line view of their package structure.

But personally, I prefer keeping the full hierarchy visible. It helps me better understand the module and package architecture — especially in larger codebases where structure matters.

Also, I find it more intuitive when navigating between similarly named classes across packages.

To each their own, but if you’re like me, make sure to disable Flatten Packages:

👉 Project View → Options → Appearance → Uncheck “Flatten Packages”

Do you have similar IntelliJ rituals? Or any settings you can’t live without?

Let me know in the comments — I’d love to pick up a few new tips too. 😊

Developer Tools – Is This IntelliJ Plugin a Must-Have?

Adam Tarcali — Sun, 08 Jun 2025 18:05:45 +0000

Chances are, every developer using IntelliJ has their own favorite plugins.

If I could only pick one – excluding the ones that come preinstalled – it would definitely be the Developer Tools – IntelliJ IDEs Plugin.

Why do I love it?

Because it brings so many small, everyday tools right into the IDE – tools I often need, and previously had to Google or open a terminal for.

Having them one click away just saves time and keeps my flow intact.

Let me highlight a few that I personally find the most useful:

✨ Handy Features I Use Constantly

🕒 Cron Expression Builder

Need to generate a cron string? You can build it visually in seconds – no need to memorize which field is minutes, hours, or day of the week.

📅 Date and Time Converter

Whether I need a Unix timestamp or a formatted date, it's right there – fast and customizable.

🔐 Hashing Tool

Quickly generate MD5, SHA, or other hashes – great when you need to work with APIs, auth tokens, or just test inputs.

📄 Lorem Ipsum Generator

Self-explanatory – need placeholder text for UI or emails? A few clicks, and you've got paragraphs of it.

📝 Notes

Probably the one I use the most. Drop any thought, reminder, or snippet here without polluting your codebase with // TODO or // FIXME.

Clean, accessible, and incredibly useful.

🔑 Password Generator

Need a secure password while developing something? No need to open a browser tab.

📷 QR Code & Barcode Generator

More useful than you'd think – especially for frontend developers working with mobile or packaging systems.

🧹 SQL Formatter

Have a messy SQL query? One click and it's neatly formatted – no more squinting at spaghetti.

🆔 UUID Generator

Testing something that needs unique IDs? Boom, instant UUIDs, right inside your IDE.

🎨 Color Picker

Super handy for frontend devs or game developers (hello LibGDX!).

Need a hex code or RGBA for a UI element? Grab it in seconds.

🧭 Final Thoughts

So… is it a must-have? Technically, no – it won't write your code or make architectural decisions.

It's not an AI tool.

But in real-world, everyday development, it can save you precious minutes and remove small but annoying distractions.

And honestly, for something free, lightweight, and that integrates so naturally into the IntelliJ ecosystem – it's worth a try.

🔧 Have you used this plugin? Or do you have a different favorite tool I should know about? Let me know in the comments!