- Developing Middleware in Java EE 8
- Abdalla Mahmoud
- 432字
- 2021-07-23 19:24:33
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.
- 現(xiàn)代C++編程:從入門到實(shí)踐
- 自然語言處理實(shí)戰(zhàn):預(yù)訓(xùn)練模型應(yīng)用及其產(chǎn)品化
- Objective-C應(yīng)用開發(fā)全程實(shí)錄
- Software Testing using Visual Studio 2012
- 數(shù)據(jù)結(jié)構(gòu)(Java語言描述)
- PostgreSQL 11從入門到精通(視頻教學(xué)版)
- 機(jī)械工程師Python編程:入門、實(shí)戰(zhàn)與進(jìn)階
- VMware虛擬化技術(shù)
- Node.js Design Patterns
- Python極簡(jiǎn)講義:一本書入門數(shù)據(jù)分析與機(jī)器學(xué)習(xí)
- Learning AWS
- Exploring SE for Android
- JavaScript從入門到精通(視頻實(shí)戰(zhàn)版)
- 嵌入式Linux C語言程序設(shè)計(jì)基礎(chǔ)教程
- 安卓工程師教你玩轉(zhuǎn)Android