Introduction

Listing the beans loaded into a Spring Boot application is a useful debugging tool when you want to verify component scanning, understand auto-configuration, or confirm which implementation actually ended up in the application context. The raw bean list can be noisy, so the practical goal is usually not just to print everything, but to print it in a way that helps you answer a specific wiring question.

Print Bean Names from the Application Context

The simplest option is to ask the ApplicationContext for all bean definition names and print them during startup.

1package com.example.demo;
2
3import java.util.Arrays;
4import org.springframework.boot.CommandLineRunner;
5import org.springframework.context.ApplicationContext;
6import org.springframework.context.annotation.Bean;
7import org.springframework.context.annotation.Configuration;
8
9@Configuration
10public class BeanListingConfig {
11
12    @Bean
13    CommandLineRunner printBeans(ApplicationContext context) {
14        return args -> {
15            String[] beanNames = context.getBeanDefinitionNames();
16            Arrays.sort(beanNames);
17
18            for (String beanName : beanNames) {
19                System.out.println(beanName);
20            }
21        };
22    }
23}

Sorting matters. Without it, the output order depends on registration timing and is much harder to scan.

Include the Bean Type

Names alone are not always enough. Spring can register proxies, generated infrastructure beans, and multiple beans with similar names. Printing the resolved type makes the output much more useful.

1package com.example.demo;
2
3import java.util.Arrays;
4import org.springframework.boot.CommandLineRunner;
5import org.springframework.context.ApplicationContext;
6import org.springframework.context.annotation.Bean;
7import org.springframework.context.annotation.Configuration;
8
9@Configuration
10public class BeanTypeListingConfig {
11
12    @Bean
13    CommandLineRunner printBeansWithTypes(ApplicationContext context) {
14        return args -> {
15            Arrays.stream(context.getBeanDefinitionNames())
16                .sorted()
17                .forEach(name -> {
18                    Class<?> type = context.getType(name);
19                    String typeName = type == null ? "unknown" : type.getName();
20                    System.out.printf("%s -> %s%n", name, typeName);
21                });
22        };
23    }
24}

This makes it much easier to see whether a bean came from your package, from Spring Boot auto-configuration, or from a library starter.

Filter the Output to Your Code

Real applications often contain hundreds of beans. If you only care about your own components, filter by package prefix or bean name pattern.

1package com.example.demo;
2
3import java.util.Arrays;
4import org.springframework.boot.CommandLineRunner;
5import org.springframework.context.ApplicationContext;
6import org.springframework.context.annotation.Bean;
7import org.springframework.context.annotation.Configuration;
8
9@Configuration
10public class FilteredBeanListingConfig {
11
12    @Bean
13    CommandLineRunner printApplicationBeans(ApplicationContext context) {
14        return args -> {
15            Arrays.stream(context.getBeanDefinitionNames())
16                .sorted()
17                .filter(name -> {
18                    Class<?> type = context.getType(name);
19                    return type != null && type.getName().startsWith("com.example");
20                })
21                .forEach(System.out::println);
22        };
23    }
24}

Filtering turns a wall of framework internals into something you can actually use while debugging.

Use Actuator for Runtime Inspection

If you want to inspect beans without adding custom startup code, Spring Boot Actuator exposes structured context information. Enable the endpoint and query it over HTTP.

management.endpoints.web.exposure.include=beans

curl http://localhost:8080/actuator/beans

This is often a better option in staging or shared environments where startup logs are noisy or hard to retrieve.

Know What the Bean List Does Not Tell You

A printed bean list shows what was registered, not why it was registered or whether it was selected for a particular injection point. If you are debugging conditional configuration, the condition evaluation report can be more informative than the bean dump itself.

Add this during troubleshooting:

debug=true

That causes Spring Boot to print the auto-configuration condition report at startup, which explains why certain configuration classes matched or were skipped.

Common Pitfalls

The most common mistake is assuming that bean presence means your application is using that bean. Spring may have several candidates of the same interface type, and an injection point may be selecting one through @Primary, qualifiers, or conditional configuration.

Another issue is printing the full context in production logs. Bean names can reveal internal structure, cloud integrations, data access layers, and security wiring. That is acceptable during focused debugging, but it should not become a permanent default.

It is also easy to ignore parent and child contexts. In more complex applications, especially tests or servlet-based setups, the context you print may not be the only one in play.

Finally, do not use bean dumping as a substitute for better diagnostics. If the real question is "why did my bean not load", the condition report and package scan boundaries often answer that faster than a raw list.

Summary

• Use ApplicationContext.getBeanDefinitionNames() to print loaded bean names.
• Include bean types and sorting to make the output readable.
• Filter by package or name when the context is too large to inspect directly.
• Prefer Actuator for structured runtime inspection.
• Use Boot's debug condition report when you need to know why a bean was or was not created.