Java EE CDI programmatic dependency disambiguation example - Injection Point inspection

In Java EE CDI it is possible to provide multiple implementations of a given interface - or service - to the service clients. In this tutorial we will see how to implement a dynamic mechanism for fetching the correct implementation based on the service client requirements.

This tutorial considers the following environment:

1. JDK 1.7.0.21
2. Weld 1.1.10

Weld is the CDI reference implementation

We start by defining a simple interface and a couple of interface implementations to serve as an example in this tutorial:

package com.byteslounge.service;

public interface NotificationService {

  void sendNotification();

}

package com.byteslounge.service.impl;

import com.byteslounge.service.NotificationService;

public class EmailNotificationService implements NotificationService {

  @Override
  public void sendNotification() {
    System.out.println("Sending email notification");
  }

}

package com.byteslounge.service.impl;

import com.byteslounge.service.NotificationService;

public class SmsNotificationService implements NotificationService {

  @Override
  public void sendNotification() {
    System.out.println("Sending SMS notification");
  }
	
}

Now we define a Java annotation that will provide a way for service clients to define which implementation they want injected. Note that this is not a CDI Qualifier.

package com.byteslounge.service;

import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import com.byteslounge.service.impl.EmailNotificationService;
import com.byteslounge.service.impl.SmsNotificationService;

@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD})
public @interface NotificationServiceType {
  
  ServiceType value();
  
  public enum ServiceType{

    EMAIL(EmailNotificationService.class),
    SMS(SmsNotificationService.class);
    
    Class<? extends NotificationService> clazz;
    
    private ServiceType(Class<? extends NotificationService> clazz){
      this.clazz = clazz;
    }

    public Class<? extends NotificationService> getClazz() {
      return clazz;
    }
  }
}

What are we doing here? We are defining a Java annotation which value - SMS or EMAIL - contains a reference to the respective service implementation type (or class). This annotation will be useful later to provide a way for clients to determine which service implementation they want injected:

@Inject
@NotificationServiceType(ServiceType.SMS)
private NotificationService notificationService;

Now we define a Producer that will serve as a factory of NotificationService implementations. The Producer and will also do dynamic dependency resolution based on the client injection point annotation:

package com.byteslounge.service.impl;

import javax.enterprise.inject.Any;
import javax.enterprise.inject.Instance;
import javax.enterprise.inject.Produces;
import javax.enterprise.inject.spi.Annotated;
import javax.enterprise.inject.spi.InjectionPoint;

import com.byteslounge.service.NotificationService;
import com.byteslounge.service.NotificationServiceProducer;
import com.byteslounge.service.NotificationServiceType;

public class NotificationServiceFactory {

  @Produces
  @NotificationServiceProducer
  public NotificationService createNotificationService(
    @Any Instance<NotificationService> instance, InjectionPoint ip){
    
    Annotated annotated = ip.getAnnotated();
    NotificationServiceType notificationTypeAnnotation =
       annotated.getAnnotation(NotificationServiceType.class);

    Class<? extends NotificationService> notificationServiceType =
       notificationTypeAnnotation.value().getClazz();

    return instance.select(notificationServiceType).get();
    
  }
}

This producer will be responsible for providing NotificationService implementations. It takes a couple of parameters:

The first one is of type Instance and parameterized with NotificationService type. It is also annotated with the @Any qualifier so it will be ready to fetch any available implementation of NotificationService type (All CDI managed beans have the @Any qualifier by default).

The second parameter is a reference to the client injection point, ie. the one where the client used @Inject in order to inject a service implementation.

In the producer method body we are basically fetching the @NotificationServiceType annotation used by the client injection point and extracting its information. Based on the annotation value we select the correct bean implementation from the Instance reference.

One should note here that there is an extra annotation being used: @NotificationServiceProducer. This annotation is a CDI Qualifier and is used in order to disambiguate between the producer method and the bean implementations themselves. So in fact, the client injection point becomes:

@Inject
@NotificationServiceProducer
@NotificationServiceType(ServiceType.SMS)
private NotificationService notificationService;

The extra CDI Qualifier is defined as:

package com.byteslounge.service;

import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import javax.inject.Qualifier;

@Qualifier
@Retention(RUNTIME)
@Target({FIELD, TYPE, METHOD})
public @interface NotificationServiceProducer {
	
}

If we didn't used this extra Qualifier - both in the producer method and injection point - the container would not know that the injected implementation should come from the CDI Producer and not from the implementation classes themselves being directly injected.

This tutorial is an example of what can be done by inspecting CDI Injection Points to determine component dependencies and other injection point characteristics.

We used a Java Enum to carry the info about the implementation desired by the client, but we could have done something even more dynamic, like passing a property in the Injection Point that would be used in an even more dynamic dependency resolution strategy.

You can find a downloadable sample at the end of this page containing the implementation described above. The sample is configured to be run on Tomcat and the service is injected into a testing servlet.

• Java EE CDI - Inject beans from external (3rd party) libraries example
• Java EE CDI dependency disambiguation example
• Java EE CDI Dependency Injection (@Inject) tutorial
• Java EE CDI Extension example