Introduction
There are situations where you need to access the CDI system programmatically, instead of using annotations like @Inject
- You want to retrieve a CDI bean within a context (class) which isn’t CDI-aware.
- It is easier to retrieve an optional or multiple beans programmatically instead of using Instance.
Since CDI 1.1 (Java EE 6), this can be easily achieved by using
CDI.current();
The programmatic access is most useful if you are creating a library/framework or some reusable piece of functionality. But I guess everyone who creates more than 1 application is in the situation where things can be reused.
This blog shows the equivalent programmatic constructs but most importantly, how you can unit test your bean in those cases (no CDI container needed!)
Optional CDI bean
An optional bean is interesting in the situation where you define some basic functionality but in case the developer defines a CDI bean implementing the interface, that custom developer logic is executed.
public interface SomeInterface {}
// with classic injection
@Inject
private Instance<SomeInterface> optional;
// Within a method
if (!optional.isUnsatisfied()) {
optional.get();
}
// programmatic
// Within method
Instance<SomeInterface> instance = CDI.current().select(SomeInterface.class);
instance.isUnsatisfied() ? null : instance.get();
Multiple beans
Within a Chain of Responsibility pattern or the situation where you can have multiple add-ons which perform some logic in a certain situation, are the ideal situations for having multiple CDI beans implementing an interface.
// with classic injection
@Inject
private Instance<SomeInterface> addonInstances;
// Within a method
List<SomeInterface> addons = new ArrayList<>();
addonInstances.iterator().forEachRemaining(
addons::add
);
// programmatic
// Within a method
List<SomeInterface> addons = new ArrayList<>();
for (SomeInterface addon : CDI.current().select(SomeInterface.class)) {
result.add(addon);
}
Sending Events
One of the nice features of CDI is the ability to sends events between consumers and producers without the need of registering the consumers with the producer for example.
Producing the Event can be done using
// with classic injection
@Inject
private Event<Payload> payloadEvent;
// Within a method
payloadEvent.fire(new Payload());
// programmatic
// within a method
CDI.current().getBeanManager().fireEvent(new Payload());
Unit Testing
Now that you have used some CDI bean retrievals in a programmatic fashion, what happens when you execute a unit test?
java.lang.IllegalStateException: Unable to access CDI
When running with plain Java, without any CDI container, you get this message because the API doesn’t contain an implementation, only the specification of the behavior.
You can of course switch to integration testing, where you launch a proper CDI container. But you can, of course, stay with your basic unit testing and have a simple, minimalistic Cdi container implementation (which is by the way not very difficult to create)
Suppose we have following code
public SomeInterface readOptionalInstance() {
Instance<SomeInterface> instance = CDI.current().select(SomeInterface.class);
return instance.isUnsatisfied() ? null : instance.get();
}
And we like to test this piece of code then the optional bean is not defined with something like this
@Test
public void readOptionalInstance_NotPresent() {
Assert.assertNull(viewBean.readOptionalInstance());
}
We need a simple CDI implementation. This is provided by the be.atbash.util.BeanManagerFake class, available in the tests artifact of atbash utils-cdi.
<dependency>
<groupId>be.atbash.utils</groupId>
<artifactId>utils-cdi</artifactId>
<version>0.9.0</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>2.13.0</version>
<scope>test</scope>
</dependency>
The CDI fake container (as in not real implementation, maybe not the correct term in the test concepts Dummy/Fake/Stub/Spy) is using Mockito underneath, so that is also a dependency we need to add to the project.
The test can then be adapted as follow
private BeanManagerFake beanManagerFake = new BeanManagerFake();
@After
public void cleanup() {
beanManagerFake.deregistration();
}
@Test
public void readOptionalInstance_NotPresent() {
beanManagerFake.endRegistration();
Assert.assertNull(viewBean.readOptionalInstance());
}
We can instantiate the BeanManagerFake as a regular bean. Important here is the deregistration method after the test is finished. It is the idea to keep the fake CDI container between tests alive but only clear the contents. In the current version, the container is also unset which makes it necessary that the beanManagerFake variable is an instance variable (and not a class variable)
With the endRegistration method, we signal that all configuration of the CDI container has taken place and that the operational modus can start. It can give some instances of interfaces if needed as in our test example.
Here we didn’t register anything, so we get a null back.
This is updated test class which contains also a test in the case we specify an instance in the CDI container.
@RunWith(MockitoJUnitRunner.class)
public class ViewBeanTest {
private ViewBean viewBean = new ViewBean();
@Mock
private SomeInterface mockClass;
private BeanManagerFake beanManagerFake = new BeanManagerFake();
@After
public void cleanup() {
beanManagerFake.deregistration();
}
@Test
public void readOptionalInstance_NotPresent() {
beanManagerFake.endRegistration();
Assert.assertNull(viewBean.readOptionalInstance());
}
@Test
public void readOptionalInstance_Present() {
beanManagerFake.registerBean(mockClass, SomeInterface.class);
beanManagerFake.endRegistration();
Assert.assertNotNull(viewBean.readOptionalInstance());
Assert.assertTrue(viewBean.readOptionalInstance() == mockClass)
}
}
You can see that we can define a mock (with the @Mock of Mockito) as a bean within the CDI container with the registered bean. We supply the instance and the type to which this instance must be bound. Within CDI, an instance can be bound to multiple class instances like the class itself, the interface, Object.class etc …) This is also possible with BeanManagerFake as the second parameter of the registerBean method is a varargs with all the class values.
And if you run the above test, you will see they are all green, so we, in fact, get the exact instance of the CDI bean (here the mock) back as the return value of the method.
Of course, when you have very complex Cdi constructions, it is better to test them in a real CDI container. But if the focus is on the business logic, the simple CDI container for testing will do.
Code
The code of BeanManagerFake is available in the Atbash utils GitHub repository and artifacts are on Maven Central.
Conclusion
Using the programmatic interfaces of the CDI container is easier in those cases where you need to retrieve optional or multiple CDI beans. And of course in the context where the dependency injection isn’t available. And with the help of the BeanManagerFake, a simple CDI container for testing, Unit tests are possible which make is easier then to set up a full blown integration test with a container.
Have fun.
