Working with CDI Bean in Java
Creating your CDI bean
A CDI bean is an application component that encapsulates some business logic. Beans can be used either by a Java code or by the unified EL (expression language used in JSP and JSF technologies). The beans’ life cycles are managed by the container and can be injected into other beans. To define a bean, all you need to do is to write a POJO and declare it to be a CDI bean. To declare this, there are two primary approaches:
- Using annotations
- Using the xml file
Both ways should work; however, folks prefer using annotations over XML as it’s handy and included in the actual coding context. So, why is XML still there? Well, that’s because annotations are relatively new in Java (released in Java 5). Until they were introduced, there was no other way in Java other than XML to provide configuration information to the application server. And since then, it continued to be just another way, alongside the annotations approach.
Moreover, if both are used together, XML is going to override annotations. Some developers and application administrators tend to perform temporary changes or hot-fixes at times, by overriding some hard-coded programmatic configuration values, using external XML files. It’s worth mentioning that this approach is not a recommended way to actually deploy things into your production.
In this article, you’ll use the annotations approach. Now, start by defining your first CDI bean:
First CDI bean
Perform the below steps:
- Defining a CDIbean – Start the first step by creating a new Java class with the name MyPojo, and then write the following code:
@Dependent
public class MyPojo
public String getMessage() {
return "Hello from MyPojo !";
}
}
This bean is nothing more than a plain old Java object, annotated with the @Dependent annotation. This annotation declares that your POJO is a CDI component, which is called the dependent scope. The dependent scope tells the CDI context that whenever you request an injection to this bean, a new instance will be created.
- Now, inject your baby CDIbean into another component. Use a servlet as an example to this. Create a servlet named ExampleServlet and write the following code:
@WebServlet(urlPatterns = "/cdi-example-1")
public class ExampleServlet extends HttpServlet {
@Inject
private MyPojo myPojo;
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
resp.getOutputStream().println(myPojo.getMessage());
}
}
You have used the @Inject annotation to obtain an instance to the MyPojo class. Now run the application and visit http://localhost:8080/EnterpriseApplication1-war/cdi-example-1. You should see a page with the following text:
Hello from MyPojo !
Congratulations! You have created and used your first CDI bean.
Providing alternative implementations to your bean
One of the greatest features of CDI is that you can provide two or more different implementations to the same bean. This is very useful if you wish to do one of the following:
- Handling client-specific business logic that is determined at runtime; for example, providing different payment mechanisms for a purchase transaction
- Supporting different versions for different deployment scenarios; for example, providing an implementation that handles taxes in the USA and another one for Europe
- Easier management for test-driven development; for example, you can provide a primary implementation for production and another mocked one for testing
To do this, you should first rewrite your bean as an abstract element (abstract class or interface) to provide different implementations according to the basic OOP principles. Now rewrite your bean to be an interface as follows:
public interface MyPojo {
String getMessage();
}
Create an implementation class to your new interface:
@Dependent
public class MyPojoImp implements MyPojo{
@Override
public String getMessage() {
return "Hello CDI 2.0 from MyPojoImp";
}
}
Now, without any modifications to the servlet class, you can test re-run your example; it should give the following output:
Hello from MyPojoImp !
What happened at runtime? The container received your request to inject a MyPojo instance. Since the container has detected your annotation over an interface and not a class stuffed with an actual implementation, it has started looking for a concrete class that implements this interface. After this, the container has detected the MyPojoImp class that satisfies this criterion. Therefore, it has instantiated and injected it for you.
Now provide different implementations. For this, you’ll need to create a new class that implements the MyPojo interface. Create a class called AnotherPojoImp as follows:
@Dependent
public class AnotherPojoImp implements MyPojo{
@Override
public String getMessage() {
return "Hello CDI 2.0 from AnotherPojoImp";
}
}
Seems simple, right? But if you checked your servlet code again and if you were in the container shoes, how would you be able to determine which implementation should be injected at runtime? If you tried to run the previous example, you will end up with the following exception:
Ambiguous dependencies for type MyPojo with qualifiers @Default
You have an ambiguity here, and there should be some meaning to specify which implementation version should be used at runtime. In CDI, this is achieved using qualifiers.
Using qualifiers
A qualifier is a user-defined annotation that is used to tell the container which version of the bean implementation you wish to use at runtime. The idea of qualifiers is too simple; you define a qualifier, and then you annotate both the bean and injection point with this qualifier.
Now define your first qualifier for the newly created bean implementation and create a new annotation with the following code:
@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface AnotherImp {
}
As you see, the qualifier is a custom-defined annotation, which itself is annotated with the @Qualifier annotation. @Qualifier tells the container that this annotation will act as a qualifier, while @Retention(RUNTIME) tells the JVM that this annotation should be available for reflection use at runtime. This way the container can check for this annotation at runtime. @Target{TYPE, METHOD, FIELD, PARAMETER} tells the compiler that this annotation can be used on types, methods, fields, and parameters. Note that the @Qualifier annotation is the key annotation here.
Here is the summary of the annotations to make it clearer:
| Annotation | Description |
| @Qualifier | Tells CDI that this annotation is going to be used to distinguish between different implementations to the same interface. |
| @Retention(RUNTIME) | Tells JVM that this annotation is intended to be used at runtime. Required for qualifiers. |
| @Target({TYPE, METHOD, FIELD, PARAMETER}) | Tells JVM that this annotation can be used on the mentioned syntax elements. |
Now, add the @AnotherImp annotation to AnotherPojoImp as follows:
@Dependent
@AnotherImp
public class AnotherPojoImp implements MyPojo{
@Override
public String getMessage() {
return "Hello from AnotherPojoImp";
}
}
The annotation’s role here is that it tells the container that this version of the class is called AnotherImp. Now you can reference this version by modifying the servlet as follows:
@WebServlet(urlPatterns = "/cdi-example")
public class ExampleServlet extends HttpServlet {
@Inject @AnotherImp
private MyPojo myPojo;
...
}
With Example
Hello from AnotherPojoImp
But how can you reference the original implementation MyPojoImp? There are two options available to do this:
- Defining another qualifier for MyPojoImp, like the earlier example
- Using the default qualifier
The default qualifier, as the name suggests, is the default one for any CDI bean that has not been explicitly qualified. Although an explicit declaration for the default qualifier is considered redundant and useless, it’s possible to explicitly declare your CDI bean as a default one using the @Default annotation, as shown in the following revision to the MyPojoImp class:
@Default
@Dependent
public class MyPojoImp implements MyPojo{
...
}
Again, @Default is redundant, but you should consider its existence even if you have not explicitly declared it. Now, to reference the MyPojoImp from the servlet, rewrite it as follows:
@WebServlet(urlPatterns = "/cdi-example")
public class ExampleServlet extends HttpServlet {
@Inject @Default
private MyPojo myPojo;
...
}
This way, the original MyPojoImp implementation will be injected instead. And likewise, you can eliminate the @Default annotation, as the default implementation will be used by default!
If you found this article interesting, you can explore Abdalla Mahmoud’s Developing Middleware in Java EE 8 to use Java features such as JAX-RS, EJBs, and JPAs for building powerful middleware for newer architectures such as the cloud. This book can help you become an expert in developing middleware for a variety of applications.