Understand how Spring finds and creates beans.

Discovery boundary

Component scanning starts at the application package.

With OrdersApplication in com.example.orders, the default scan searches that package and every subpackage. It finds classes such as:

com.example.orders.notification.EmailNotificationSender
com.example.orders.service.OrderService
com.example.orders.configuration.TimeConfiguration
com.example.orders.runner.DemoRunner

It does not automatically scan a sibling such as com.example.payments. Put the application class at a sensible package root instead of widening the scan without a reason.

Scanning reads class metadata. It is looking for component stereotypes and configuration classes, not for every Java class in the package. An unannotated DTO in the same folder is visible to Java but does not become a bean merely because the scanner passed over it.

package com.example.orders;

@Service
class OrderService { }
// registered by component scanning

class CreateOrderRequest { }
// ordinary class; no bean definition is registered

Two creation paths

Use scanning for your components and @Bean for explicit construction.

@Configuration(proxyBeanMethods = false)
public class TimeConfiguration {

    @Bean
    public Clock applicationClock() {
        return Clock.systemUTC();
    }

    @Bean
    public OrderTimestampService orderTimestampService(
            Clock applicationClock
    ) {
        return new OrderTimestampService(applicationClock);
    }
}

The default bean names here are applicationClock and orderTimestampService, taken from the method names. Spring resolves the Clock parameter before invoking the second method.

@Configuration is itself a component stereotype, so the scan finds TimeConfiguration. Spring then processes its @Bean methods as additional definitions.

1. 01

   Find TimeConfiguration

   The default component scan discovers the configuration class.

2. 02

   Register both method definitions

   The declared return types tell Spring that a Clock and an OrderTimestampService can be created.

3. 03

   Resolve method parameters

   Spring finds the managed Clock before calling the service factory method.

4. 04

   Register returned objects as beans

   The object returned from each method is managed by the context.

Choosing the creation path

The decision is about ownership and construction, not class importance.

Avoid defining the same application service both with @Service and an unrelated @Bean method unless two distinct definitions are intentional. Otherwise the context may contain two candidates of the same type and injection becomes ambiguous.

@Service
class OrderService { }

@Bean
OrderService orderService() {
    return new OrderService();
}

// These are two bean definitions, not two annotations
// describing one shared instance.

proxyBeanMethods

With proxies disabled, direct method calls are ordinary Java calls.

@Configuration(proxyBeanMethods = false) avoids method interception. It is efficient and clear when bean methods are independent or receive other beans as parameters.

// Correct: Spring supplies its managed TokenGenerator bean.
@Bean
public OtpService otpService(TokenGenerator tokenGenerator) {
    return new OtpService(tokenGenerator);
}

// Risky with proxyBeanMethods = false:
@Bean
public OtpService anotherOtpService() {
    return new OtpService(tokenGenerator());
    // tokenGenerator() is a normal Java call and creates another instance.
}

The default @Configuration mode uses a proxy that can intercept calls between @Bean methods and return the managed bean. Parameter injection works in either mode and states the dependency more directly.

@Configuration(proxyBeanMethods = false)
class TokenConfiguration {

    @Bean
    TokenGenerator tokenGenerator() {
        return new TokenGenerator();
    }

    @Bean
    OtpService otpService() {
        return new OtpService(tokenGenerator());
    }
}

// Context bean A: created from tokenGenerator()
// Plain object B: created when otpService() calls tokenGenerator()
// OtpService receives B, not the managed bean A.

@Bean
OtpService otpService(TokenGenerator tokenGenerator) {
    return new OtpService(tokenGenerator);
}

Managed and ordinary objects

Spring should manage services and infrastructure, not every object.

Spring-managed objects participate in injection, scopes and lifecycle callbacks. Short-lived domain values—request DTOs, entities, value objects and exceptions—are normally created by application or persistence code. They do not need to be fetched from the ApplicationContext.

When a managed service needs another managed object, constructor injection is the normal path. Direct context access remains an integration escape hatch, not the default application design.

@Bean
Clock applicationClock() {
    return Clock.systemUTC();
}
// The returned Clock is a bean because Spring invokes
// this definition and registers the result.

Instant timestamp = applicationClock.instant();
// The Instant is a normal value returned during business work.
// It does not become a bean.

Calling new inside a @Bean method is completely normal: the returned object is precisely what Spring is being asked to manage. Calling new inside a service for one of its required collaborators bypasses injection and recreates the coupling from module 1.

Inject time

Clock turns the current time into a replaceable dependency.

Clock fixedClock = Clock.fixed(
        Instant.parse("2026-08-31T00:00:00Z"),
        ZoneOffset.UTC
);

Clock.fixed(...) always returns the same instant. That is useful in this learning checkpoint and in tests. A production bean usually returns Clock.systemUTC(), while a test configuration supplies a fixed clock.

public class OrderTimestampService {
    private final Clock clock;

    public OrderTimestampService(Clock clock) {
        this.clock = clock;
    }

    public Instant currentTimestamp() {
        return clock.instant();
    }
}

Clock.systemUTC()

Clock.fixed(
    instant,
    ZoneOffset.UTC
)

Clock.offset(
    baseClock,
    Duration.ofMinutes(5)
)

Clock testClock = Clock.fixed(
        Instant.parse("2026-08-31T00:00:00Z"),
        ZoneOffset.UTC
);
OrderTimestampService service =
        new OrderTimestampService(testClock);

assertEquals(
        Instant.parse("2026-08-31T00:00:00Z"),
        service.currentTimestamp()
);

The service is tested as plain Java. Spring configuration decides which clock production receives; the class itself remains independent of the container.

When direct context access is justified

Use ApplicationContext at integration boundaries, not as hidden injection.

Even dynamic selection often has a cleaner injectable form, such as injecting a map of strategies into a dedicated registry. Reach for the context only when the boundary truly needs container-level behaviour.