官术网_书友最值得收藏!

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 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. Let's rewrite our bean to be an interface as follows:

public interface MyPojo { 
    String getMessage(); 
} 

Next, we will create an implementation class to our 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, we can test re-run our example; it should give the following output:

Hello from MyPojoImp !

What happened at runtime? The container has received your request to inject a MyPojo instance; since the container has detected your annotation over an interface, not a class stuffed with an actual implementation, it has started looking for a concrete class that implements this interface. After that, the container has detected the MyPojoImp class that satisfies this criterion. Therefore, it has instantiated and injected it for you.

Now, let's go on with the critical part of the story, which is providing one more different implementations. For that, of course, we will need to create a new class that implements the MyPojo interface. Let's 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 our 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

We have an ambiguity here, and there should have some mean to specify which implementation version that should be used at runtime. In CDI, this is achieved by using qualifiers, which will be the topic of the next section.

主站蜘蛛池模板: 和田市| 广西| 黔南| 资阳市| 平遥县| 盐源县| 松原市| 通化市| 宜城市| 景洪市| 富平县| 普定县| 荔波县| 东源县| 闽侯县| 射阳县| 泸溪县| 兴国县| 萍乡市| 阳高县| 府谷县| 柳河县| 荣昌县| 棋牌| 南平市| 泽普县| 扬中市| 望江县| 信宜市| 吉隆县| 广河县| 开封县| 南通市| 尚志市| 四子王旗| 吉安县| 周口市| 乌拉特前旗| 柘城县| 绥芬河市| 石家庄市|