CDI — Contexts & Dependency Injection

What is CDI, and How Does it Relate to Spring DI?

CDI (Contexts and Dependency Injection) is the Jakarta EE standard specification for dependency injection and contextual lifecycle management. Like Spring IoC, it solves the same core problem: instead of your code manually constructing dependencies with new, a container creates, wires, and manages the lifecycle of your objects.

The key distinction: CDI is a specification (defined in jakarta.inject.* and jakarta.enterprise.context.*), implemented by containers like Weld (the reference implementation, used in WildFly) and OpenWebBeans (used in TomEE). Spring DI is a framework implementation — it predates CDI and inspired parts of it, but follows its own model. When you use Quarkus, you're using CDI directly (via ArC, Quarkus's CDI implementation). When you use Spring Boot, you're using Spring DI — though Spring also honours @Inject from jakarta.inject as an alternative to @Autowired.

// BEFORE: tight coupling — impossible to test without a real Database
public class OrderService {
    private PaymentService payment = new PaymentService();  // hard dependency
    private EmailService   email   = new EmailService();    // another hard dependency
}

// AFTER CDI: loose coupling — container injects; test can inject mocks
@ApplicationScoped
public class OrderService {

    private final PaymentService payment;
    private final EmailService   email;

    @Inject  // constructor injection — preferred, same as Spring
    public OrderService(PaymentService payment, EmailService email) {
        this.payment = payment;
        this.email   = email;
    }
}

Injection Styles — and Why Constructor Is the Right Default

// ✅ Constructor injection — preferred in CDI and Spring alike
@ApplicationScoped
public class ReportService {
    private final UserRepository users;
    private final PdfGenerator   pdf;

    @Inject
    public ReportService(UserRepository users, PdfGenerator pdf) {
        this.users = users;
        this.pdf   = pdf;
        // fields are final — can't accidentally be null or reassigned
    }
}

// ⚠️  Field injection — tempting but problematic
@ApplicationScoped
public class ReportService {
    @Inject private UserRepository users;  // can't be final
    @Inject private PdfGenerator   pdf;    // invisible dependencies in unit tests
    // to unit test, you need a CDI container or reflection-based injection
}

// Setter injection — for optional dependencies only
@ApplicationScoped
public class NotificationService {
    private SmsGateway smsGateway;  // optional — may not be configured in all envs

    @Inject
    public void setSmsGateway(@Any Instance<SmsGateway> gateway) {
        if (gateway.isResolvable()) {
            this.smsGateway = gateway.get();
        }
    }
}

CDI Scopes — How Long a Bean Lives

@RequestScoped      // one instance per HTTP request — destroyed when the request ends
@SessionScoped      // one instance per HTTP session — must implement Serializable
@ApplicationScoped  // one instance for the app lifetime — effectively a singleton
@ConversationScoped // developer-controlled: spans multiple requests when explicitly kept alive
@Dependent          // default: one instance per injection point — no shared state

// @RequestScoped — data that belongs to exactly one request
@RequestScoped
public class RequestContext {
    private String correlationId = UUID.randomUUID().toString();
    private Instant requestStart = Instant.now();
    // getters, no setters — this data doesn't change within one request
}

// @SessionScoped — user state across multiple requests
@SessionScoped
public class UserSession implements Serializable {  // Serializable required for clustering
    private Long userId;
    private String username;
    private Set<String> roles = new HashSet<>();
    // keep small — sessions are replicated across cluster nodes
}

// @ApplicationScoped — shared state or heavyweight resources, initialised once
@ApplicationScoped
public class ConfigService {
    private Map<String, String> config;

    @PostConstruct
    public void load() {
        config = loadConfigFromDatabase();  // runs once — result cached for app lifetime
    }
}

Client Proxies — How CDI Handles Scope Differences

CDI almost never injects the real bean instance into another bean. It injects a client proxy — a generated subclass that intercepts every method call and forwards it to the correct real instance for the current context. This is what makes scope mismatches safe and what enables interceptors to work transparently.

/*
 *  @ApplicationScoped bean holds a reference to a @RequestScoped bean:
 *
 *  ┌─────────────────────────────────┐
 *  │ ConfigService (@ApplicationScoped) │
 *  │                                  │
 *  │  @Inject                         │
 *  │  RequestContext ctx;             │ ← this is NOT a real RequestContext
 *  │                                  │   it's a CLIENT PROXY
 *  └─────────────────────────────────┘
 *              │
 *              │  every method call is forwarded by the proxy
 *              ▼
 *  ┌──────────────────────────────────────────────────────┐
 *  │  Proxy looks up the correct RequestContext instance  │
 *  │  for the CURRENT thread / HTTP request               │
 *  │  and delegates the call there                        │
 *  └──────────────────────────────────────────────────────┘
 *
 *  Request 1 → proxy resolves to RequestContext instance A
 *  Request 2 → proxy resolves to RequestContext instance B
 *  The proxy reference in ConfigService never changes.
 */

@ApplicationScoped
public class AuditService {

    @Inject
    private RequestContext ctx;  // a proxy — safe to hold in @ApplicationScoped

    public void log(String action) {
        // ctx.getCorrelationId() calls through the proxy → correct per-request instance
        log.info("[{}] {}", ctx.getCorrelationId(), action);
    }
}

Qualifiers — Resolving Multiple Implementations

When two or more beans implement the same type, CDI can't choose automatically — injecting without a qualifier is an ambiguous dependency and fails at deployment. @Qualifier annotations are the disambiguation mechanism.

// Define qualifier annotations
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.TYPE, ElementType.PARAMETER})
public @interface Smtp {}

@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.TYPE, ElementType.PARAMETER})
public @interface Mock {}

// Two implementations
@Smtp @ApplicationScoped
public class SmtpEmailService implements EmailService {
    public void send(String to, String body) { /* real SMTP */ }
}

@Mock @ApplicationScoped
public class MockEmailService implements EmailService {
    public void send(String to, String body) {
        log.info("[MOCK] Email to {}: {}", to, body);
    }
}

// Inject the one you need
@ApplicationScoped
public class NotificationService {
    private final EmailService emailService;

    @Inject
    public NotificationService(@Smtp EmailService emailService) {
        this.emailService = emailService;
    }
}

Producers — Creating Beans With Custom Logic

Not every object can be annotated with a CDI scope — third-party classes, objects that require runtime parameters to construct, or objects that need a factory method. @Produces turns a method or field into a bean factory that CDI manages.

@ApplicationScoped
public class Infrastructure {

    // Produce a configured ObjectMapper as a CDI bean
    @Produces
    @ApplicationScoped
    public ObjectMapper objectMapper() {
        return new ObjectMapper()
            .registerModule(new JavaTimeModule())
            .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
    }

    // Produce a config value from a property file
    @Produces
    @Named("apiBaseUrl")
    public String apiBaseUrl() {
        return System.getenv().getOrDefault("API_BASE_URL", "http://localhost:8080");
    }
}

// Now ObjectMapper is injectable anywhere as a CDI bean
@ApplicationScoped
public class JsonConverter {
    private final ObjectMapper mapper;

    @Inject
    public JsonConverter(ObjectMapper mapper) { this.mapper = mapper; }
}

CDI Events — Decoupled Publish/Subscribe

CDI's event system allows beans to communicate without knowing about each other. The publisher fires an event object; any bean with an @Observes method for that type receives it. No wiring, no interface contract — pure type-based dispatch.

// Event payload — a plain class, no CDI annotation needed
public record UserRegisteredEvent(Long userId, String email) {}

// Publisher — injects Event<T> and fires it
@ApplicationScoped
public class RegistrationService {

    @Inject
    private Event<UserRegisteredEvent> registrationEvent;

    public void register(String email) {
        User user = createUser(email);
        registrationEvent.fire(new UserRegisteredEvent(user.getId(), email));
        // all @Observes methods run synchronously before this line returns
    }
}

// Observers — registered automatically, no explicit subscription needed
@ApplicationScoped
public class WelcomeEmailSender {
    public void onRegistration(@Observes UserRegisteredEvent event) {
        sendWelcomeEmail(event.email());
    }
}

@ApplicationScoped
public class AnalyticsTracker {
    public void onRegistration(@Observes UserRegisteredEvent event) {
        track("user_registered", event.userId());
    }
}

// Async event — fire and continue, observer runs in a separate thread
public void registerAsync(String email) {
    User user = createUser(email);
    registrationEvent.fireAsync(new UserRegisteredEvent(user.getId(), email));
    // returns immediately — observers run concurrently
}

Interceptors — Cross-Cutting Concerns Without Inheritance

// Step 1: define an interceptor binding annotation
@InterceptorBinding
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Timed {}

// Step 2: implement the interceptor
@Timed
@Interceptor
@Priority(Interceptor.Priority.APPLICATION)
public class TimingInterceptor {

    @AroundInvoke
    public Object measure(InvocationContext ctx) throws Exception {
        long start = System.nanoTime();
        try {
            return ctx.proceed();  // invoke the actual method
        } finally {
            long ms = (System.nanoTime() - start) / 1_000_000;
            log.debug("{}.{}() took {}ms",
                ctx.getTarget().getClass().getSimpleName(),
                ctx.getMethod().getName(), ms);
        }
    }
}

// Step 3: apply it with just one annotation
@ApplicationScoped
public class ReportService {

    @Timed  // interceptor runs transparently — zero change to business logic
    public Report generate(Long userId) { ... }
}

Bean Discovery — What CDI Scans and What It Ignores

CDI needs to know which classes to consider as beans. This is controlled by bean-discovery-mode in beans.xml, or by the absence of that file entirely.

<!-- src/main/resources/META-INF/beans.xml (or WEB-INF/beans.xml in a WAR) -->

<!-- annotated (recommended since CDI 1.1 / EE 7) -->
<!-- Only classes with a bean-defining annotation are considered beans -->
<beans xmlns="https://jakarta.ee/xml/ns/jakartaee"
       version="4.0"
       bean-discovery-mode="annotated">
</beans>

<!-- all — every class in the archive is a potential bean, even without annotations -->
<!-- Only use this for legacy compatibility; slow startup, unexpected beans -->
<beans bean-discovery-mode="all"></beans>

<!-- none — CDI disabled for this archive entirely -->
<beans bean-discovery-mode="none"></beans>

Bean-defining annotations (the ones that make a class discoverable in annotated mode):

Interview Questions