Before version 2.0, the CDI API was limited only to the scope of Java EE. Now and with CDI 2.0, the community did great in extending the scope of CDI into Java SE. Yes, like Spring and Google Guice, you can now use CDI in nearly any Java application.

If you are familiar enough with CDI, let's take a look at the new features that were added in CDI 2.0:

• CDI support in Java SE
• Ability to order events
• Asynchronous event
• Configurators for major SPI elements
• Possibility to configure or veto observer methods
• Add built-in annotation literals
• Make it possible to apply interceptors on producers
• Alignment on Java 8 features (streams, lambdas, repeating qualifiers)

A CDI bean is an application component that encapsulates some business logic. Beans can be used either by some Java code or by the unified EL (expression language used in JSP and JSF technologies). Beans' life cycles are managed by the container and can be injected into other beans. All you need to do to define a bean is to write a POJO and declare it to be a CDI bean. To declare that, there are two primary approaches:

• Using annotations
• Using the beans.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 just over 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 than XML to provide configuration information to your application...

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 that, we should first rewrite our bean as an abstract element (abstract class or interface) and then we will be able to provide different implementations according to the basic OOP principles...

CDI beans, according to the specification, are described to be contextual. By contextual it's meant that each CDI bean has a well-defined scope that it lives in. A scope describes the lifetime of the bean, that is, when the CDI bean shall be created and when it shall be destroyed. To make this more clear, consider the earlier examples where we have injected our beans into a servlet. The question is: will I obtain the same instance of the bean each time I run the example? Or will I obtain a new instance each time? Or one instance per user? Or what? The basic answer to all these questions, is specifying our bean scope.

One of the most popular examples of a bean scope that I'm pretty sure you have a prior knowledge of the singleton pattern. In this pattern, some class is supposed to have one, and only one, an instance of it in runtime. It should...

As you saw in previous examples, the @Inject annotation allows us to inject a bean as a field in another bean during its instantiation. However, the use of @Inject is not limited to fields only, as there are three valid mechanisms for injecting CDI beans:

• Direct field injection
• Bean constructor parameter injection
• Initializer method parameter injection

Direct field injection is almost the easiest and most common mechanism for injecting CDI beans. By direct field injection, we mean that we define the injection point as an instance variable within another bean, then we use the @Inject annotation to request dependency injection. We have already used this mechanism in previous examples...

As shown earlier, a bean can have different alternatives, by introducing one interface and providing different implementations, each with a different qualifier. When injecting a reference to this interface in another bean, you can annotate your injection point with the qualifier for the implementation you desire. One interesting question is, can we specify which implementation to inject according to some runtime parameters, such as a user-specified choice?

For example, suppose a user is engaged in a payment workflow process. The first step is that the user will choose which payment method they prefer and where the next step they will actually perform the payment transaction. Suppose you have a PaymentStrategy interface with different bean implementations for a credit card, PayPal, and check payment strategies. Can we specify which bean implementation to reference...

Interceptors, as the name suggests, are methods that intercept other methods. With interceptors, you can write one method that will always run before one or other methods of your choice. Interceptors are useful when you are required to implement some cross-cutting concern, which should take kind of a global effect on some other scenarios. For example, suppose you want to log each method call in a payment processor bean, so you can later check what really happened during runtime in production. The direct mechanism to implement this is to write a logging function, then call it in each method in the payment processing bean. Although this seems simple, it's really redundant with the existence of interceptors. With interceptors, you can write your logging function once, and attach it with all other methods that you need to associate logging with. Interceptors...