What are @Configuration and @Bean, and how do you use them to define a Spring bean?
answer
- class = recipe book, @Bean = one recipe
- bean name defaults to method name
- singleton by default, called once
- params are autowired dependencies
- for third-party classes you can't annotate
basics
~10 s@Configuration marks a class as a source of bean definitions. Inside it, a method annotated with @Bean returns an object that Spring registers as a bean in the application context, managing its lifecycle.
solid answer
~40 s@Configuration marks a class as a container-managed source of bean definitions — Java config, the alternative to XML. Each method annotated with @Bean is a factory method: Spring calls it once, takes the returned object, and registers it as a singleton bean in the ApplicationContext. The bean's name defaults to the method name (overridable via @Bean("name")). Method parameters are autowired from other beans, which is how you express dependencies between beans. @Configuration classes are themselves detected by component scanning (they are meta-annotated with @Component) or registered explicitly. This gives you type-safe, refactor-friendly wiring and is the standard way to configure third-party objects you can't annotate with @Component (like a DataSource or RestTemplate).
code
java · 16 lines@Configuration
class AppConfig {
@Bean
DataSource dataSource() {
HikariDataSource ds = new HikariDataSource();
ds.setJdbcUrl("jdbc:postgresql://localhost/app");
return ds;
}
// method parameter is autowired from the container
@Bean
JdbcTemplate jdbcTemplate(DataSource dataSource) {
return new JdbcTemplate(dataSource);
}
}go deeper
Know that @Configuration is on the class and @Bean is on a method that returns a managed object; bean name = method name; singleton by default.
Explain parameter autowiring for inter-bean dependencies and the @Component vs @Bean decision, plus name/scope overrides.
Position Java config against XML and component scanning, mention that @Configuration is a @Component, and note the private/final method restriction hinting at CGLIB.
Frame @Bean methods as programmatic BeanDefinition registration and connect to lifecycle, conditionals (@Conditional), and how auto-configuration is built on the same mechanism.
## The problem it solves Spring needs to know which objects to create and manage (its **beans**) and how to wire them together. `@Component` + component scanning works for *your* classes, but you can't put `@Component` on a class you don't own (e.g. `RestTemplate`, a `DataSource`, an SDK client). **Java configuration** solves this: you write plain methods that construct those objects and let Spring manage the results. ## @Configuration `@Configuration` is a class-level annotation (itself meta-annotated with `@Component`, so it's picked up by component scanning). It declares that the class contains **bean definitions**. Think of the class as a recipe book and each `@Bean` method as one recipe. ## @Bean `@Bean` is a method-level annotation. The method is a **factory method**: Spring invokes it, and whatever object it returns becomes a bean in the **ApplicationContext** (Spring's container / registry of managed objects). Key defaults and options: - **Bean name** defaults to the *method name*. Override with `@Bean("myName")` or `@Bean(name = {"a", "b"})` for aliases. - **Scope** defaults to **singleton** — Spring calls the method once and caches the single instance. Add `@Scope("prototype")` for a new instance per lookup. - **Dependencies** are declared as method *parameters*: Spring resolves each parameter by autowiring a matching bean before calling the method. You can also just call another `@Bean` method directly (inter-bean reference) — see full-mode behavior. - **Return type** should be as specific as useful; the declared return type participates in type-based autowiring. ## Minimal example ```java @Configuration class AppConfig { @Bean DataSource dataSource() { var ds = new HikariDataSource(); ds.setJdbcUrl("jdbc:postgresql://localhost/app"); return ds; } @Bean JdbcTemplate jdbcTemplate(DataSource dataSource) { // autowired param return new JdbcTemplate(dataSource); } } ``` Here `jdbcTemplate` depends on `dataSource`; Spring supplies the already-created `DataSource` singleton. ## How it gets loaded - Via component scanning (`@ComponentScan` / Spring Boot auto-config finds `@Configuration` because it's a `@Component`), or - Explicitly: `new AnnotationConfigApplicationContext(AppConfig.class)`, or `@Import(AppConfig.class)`. ## When to use @Bean vs @Component - `@Component`/`@Service`/`@Repository` — for **your own** classes; Spring instantiates them by scanning. - `@Bean` — for **third-party** classes, when construction needs logic/conditionals, or when one method needs to produce several related objects. ## Common gotchas - Forgetting the class-level `@Configuration` (or having only `@Bean` methods in a plain `@Component`) changes semantics ("lite mode" — inter-bean calls create new instances). Covered in the full-vs-lite question. - Two `@Bean` methods with the same method name = duplicate bean names; the second may override or fail depending on `allow-bean-definition-overriding`. - `@Bean` methods must not be `private` or `final` in a full `@Configuration` class (CGLIB needs to override them).
- What is the default name and scope of a @Bean, and how do you change them?Default name is the method name; default scope is singleton. Override the name with @Bean("name"), and the scope with @Scope("prototype") (or another scope) on the same method.
- When would you use @Bean instead of @Component?When the class isn't yours to annotate (third-party types like RestTemplate/DataSource), when construction needs conditional or imperative logic, or when one factory method must produce/assemble several collaborating objects.
saying these in an interview costs you the question
- Saying @Bean goes on a class (it's method-level; @Configuration is class-level).
- Claiming the default scope is prototype (it's singleton).
- Thinking @Bean methods can't take parameters — parameters are the primary way to inject dependencies.
- Believing you must use XML because a class is third-party — that's exactly what @Bean avoids.