In this chapter, we looked at CDI, the standard API for managed beans with conversational scope in Java EE 7.
- Context: The ability to bind lifecycle and interactions to stateful components together in a semantic encapsulated boundary, which is type safe and extensible
- Dependency Injection: The ability to inject a dependent component into an object in a type safe manner and includes the capability to decide on the implementation of those dependent components at runtime
We saw that CDI is a very elegant solution and straightforward method for dependency injection. CDI managed beans can practically be a plain old Java object (POJO). Most of the time, CDI managed beans are concrete classes, which may or may not implement one or more Java interfaces, or extend a single abstract class. A CDI bean may be declared final or have final methods, and they can be generic parameterized types. CDI supports application factories that produce managed bean types. If required, an application can also use a disposal factory in order to clean up resources. CDI support producer methods that allow the application to overcome limitations in the container. The application can supply a custom factory that creates bean types for the container. CDI also support disposal methods, which may be associated with the same factory class.
CDI managed beans can be differentiated by qualifiers, which are custom Java annotations. It is also possible to programmatically look up a bean by type and qualifier. Moreover, most applications will make use of the @Inject annotation for dependency injection.
The CDI container supports five default scopes for managed beans, namely @RequestScoped, @SessionScoped, @ApplicationScoped, @ConversationScoped, and @Dependent. It is possible to define further custom scopes. The CDI beans are automatically associated with associated contextual scope, which defines their lifecycle. In other words, CDI managed beans live their lives in a well-defined scope. However, if the bean is declared @Dependent scope then the lifecycle is managed by the JVM.
At the end of an HTTP session any associated CDI managed beans with @SessionScoped are destroyed, and then they can be garbage collected by the JVM.
At the end of an HTTP request any associated CDI managed beans with @RequestScoped are destroyed, and then they can be garbage collected by the JVM.
We learnt how to develop a standalone CDI application for Java SE using JBoss. We wrote some basic unit tests with Gradle as the build tool. Next, we moved on to the open source project DeltaSpike, which is an open source framework for a standalone CDI container with semi-portable code, and we developed test cases around more features of CDI. We increased our learning about writing abstract test case to handle the startup and shutdown of the CDI container. We saw there were limitations with such tools, and we understood them.
Finally, we moved to the Arquillian framework, which was an integration unit test framework that assembled tight bundles and deployed them to an embedded application server seamlessly. We also saw how to extend our Gradle build, and wrote more involved unit tests to see the lifecycle operations, namely post construction and pre-destruction, and how to extend CDI managed beans with Decorators and Interceptors.
In the next chapter, we will move to the EJB container, which has a different behavior to CDI and where EJBs do not have contextual scope generally.