Let Boot contribute defaults that back off cleanly.

Three different pieces

A starter brings dependencies; auto-configuration creates conditional beans.

This is why adding one dependency can change startup behaviour: a class that was absent is now present, so a classpath condition may begin to match.

notification-client.jar
    provides EmailClient

notification-spring-boot-autoconfigure.jar
    provides NotificationAutoConfiguration

notification-spring-boot-starter
    depends on both jars for convenience

A project can use the client library manually without Spring. It can use the auto-configuration with explicitly chosen dependencies. The starter simply makes the common combination easy to declare.

Candidate discovery

Auto-configuration is imported, not found by your component scan.

@EnableAutoConfiguration, included by @SpringBootApplication, asks Boot to load candidate configuration classes. A reusable library lists those candidates in:

META-INF/spring/
└── org.springframework.boot.autoconfigure.AutoConfiguration.imports

com.example.notification.NotificationAutoConfiguration

The configuration class is marked @AutoConfiguration. Merely placing it under com.example.orders is not the registration mechanism for a reusable auto-configuration.

This matters because library authors cannot predict the package of every consuming application. Package scanning is controlled by the application; the imports file is controlled by the library and travels inside its jar.

notification-spring-boot-autoconfigure/
└── src/main/
    ├── java/com/example/notification/
    │   └── NotificationAutoConfiguration.java
    └── resources/META-INF/spring/
        └── org.springframework.boot.autoconfigure.AutoConfiguration.imports

1. 01

   The application enables auto-configuration

   @SpringBootApplication includes that opt-in.

2. 02

   Boot reads candidate imports

   Every participating library can contribute configuration class names.

3. 03

   Conditions filter candidates and bean methods

   Unavailable or unwanted configurations do not contribute definitions.

4. 04

   Matching definitions join the same context

   Application components and auto-configured infrastructure are wired together through normal dependency injection.

Conditions

Every declared condition must match.

@Bean
@ConditionalOnMissingBean(NotificationSender.class)
@ConditionalOnProperty(
        prefix = "orders.notification",
        name = "enabled",
        havingValue = "true",
        matchIfMissing = true
)
public NotificationSender notificationSender() {
    return new EmailNotificationSender();
}

Here, true matches, false does not, and a missing property also matches because matchIfMissing is true.

Read conditions as predicates. The class-level condition controls whether the configuration is relevant at all. Method-level conditions control whether one particular bean definition should be added.

createDefaultSender =
        emailClientIsPresent
        && propertyAllowsNotifications
        && noNotificationSenderBeanExists;

Walk through four startups

The same auto-configuration can produce different contexts.

Back-off

User configuration has the final say.

@ConditionalOnMissingBean is the central back-off mechanism. The auto-configuration offers a useful default, while an application can replace that default simply by defining its own bean. No framework source code needs to be edited.

@Configuration(proxyBeanMethods = false)
class ApplicationNotificationConfiguration {

    @Bean
    NotificationSender notificationSender() {
        return new SmsNotificationSender();
    }
}

The application does not call or subclass the auto-configuration. Its bean definition is visible when the conditional default is evaluated, so@ConditionalOnMissingBean does not match.

Back-off is more maintainable than “create both and mark one primary.” It prevents an unwanted default from existing at all and lets a reusable library remain opinionated without becoming rigid.

Component scan versus auto-configuration

Both register beans, but they discover definitions differently.

Once registered, both kinds of definitions participate in the same container. Constructor injection does not care whether a bean originated from scanning, an application @Bean method or auto-configuration.

Diagnosing decisions

The condition evaluation report explains why configurations matched.

When startup behaviour is surprising, run with --debug or set debug=true. The condition evaluation report shows positive and negative matches and the reason for each decision.

Positive matches:
  NotificationAutoConfiguration
    - EmailClient was found
    - orders.notification.enabled was missing
      and matchIfMissing was true

Negative matches:
  notificationSender
    - NotificationSender bean already existed

A negative match is not necessarily an error. Back-off intentionally appears as a negative match. Read the reason before excluding an auto-configuration or adding annotations to force it.