How are bean names assigned during component scanning, and how do you customize them with BeanNameGenerator?

## Where bean names come from Every bean definition needs a **name** (its primary id in the registry). During scanning this is decided by a **`BeanNameGenerator`** — a strategy interface with one method: `String generateBeanName(BeanDefinition definition, BeanDefinitionRegistry registry)`. ### Default: AnnotationBeanNameGenerator The scanner uses `AnnotationBeanNameGenerator` (singleton `INSTANCE`). Its logic: 1. **Explicit value wins.** If the stereotype (or any annotation meta-annotated with `@Component`, or `jakarta.inject.Named`/`jakarta.annotation.ManagedBean`) has a non-empty `value`, that string is the bean name. So `@Service("orders")` → bean name `orders`, `@Repository("userDao")` → `userDao`. 2. **Otherwise a default name** is derived from the short class name via `Introspector.decapitalize`: `OrderService` → `orderService`, `MyController` → `myController`. ### The decapitalization edge case `Introspector.decapitalize` follows JavaBeans rules: if the **first two** characters are both uppercase, the name is left **unchanged**. So `URLParser` → `URLParser` (NOT `uRLParser`), and `ABCService` → `ABCService`. Candidates often get this wrong. ### Customizing via @ComponentScan(nameGenerator = ...) ```java @ComponentScan(basePackages = "com.app", nameGenerator = FullyQualifiedAnnotationBeanNameGenerator.class) ``` `nameGenerator` takes a `Class<? extends BeanNameGenerator>` that must have a no-arg constructor (Spring instantiates it). ### FullyQualifiedAnnotationBeanNameGenerator A built-in subclass whose default (no explicit value) name is the **fully-qualified class name** (`com.app.order.OrderService`) instead of the short name. **Why it matters:** if you scan two packages each containing an `OrderService`, the short-name generator produces two beans both named `orderService` → a **BeanDefinitionStoreException / override conflict**. FQN names are unique, eliminating the clash. Spring Boot lets you switch to it via `spring.main.name-generator` / setting it on the `SpringApplication`. ### Writing your own Implement `BeanNameGenerator` for custom conventions (e.g. prefixing by module): ```java public class ModulePrefixNameGenerator extends AnnotationBeanNameGenerator { @Override protected String buildDefaultBeanName(BeanDefinition d) { return "mod_" + super.buildDefaultBeanName(d); } } ``` You can override just `buildDefaultBeanName` to keep explicit-value handling. ### Why bean names matter - They're the key in the singleton registry and what `getBean(name)` uses. - `@Autowired` resolves **by type**, but on ambiguity falls back to the **field/parameter name matched against the bean name** (via the default candidate resolution) — and `@Resource` resolves **by name first**. So a nonstandard generator can break name-based injection expectations. - Duplicate names across scans cause **overriding** (or an error when `spring.main.allow-bean-definition-overriding=false`, the Boot default). ### Related - `DefaultBeanNameGenerator` — used for XML/generic definitions (delegates differently). - For programmatic registration you can pass a generator to `AnnotationConfigApplicationContext` / `ClassPathBeanDefinitionScanner.setBeanNameGenerator(...)`. ### Gotchas - The generator must be resolvable with a default constructor when referenced by class in `@ComponentScan`. - Changing to FQN names breaks any code/config that references beans by their short name. - Explicit `@Component("x")` values are honored regardless of the generator's default-name logic (unless you override the value-handling too).