- 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.
- 程序員面試筆試寶典(第3版)
- Visual Basic .NET程序設(shè)計(jì)(第3版)
- Instant Testing with CasperJS
- GeoServer Cookbook
- Azure IoT Development Cookbook
- NLTK基礎(chǔ)教程:用NLTK和Python庫(kù)構(gòu)建機(jī)器學(xué)習(xí)應(yīng)用
- TestNG Beginner's Guide
- Visual Basic程序設(shè)計(jì)習(xí)題解答與上機(jī)指導(dǎo)
- Full-Stack React Projects
- Monitoring Elasticsearch
- Java零基礎(chǔ)實(shí)戰(zhàn)
- Visual C#.NET Web應(yīng)用程序設(shè)計(jì)
- SpringBoot從零開始學(xué)(視頻教學(xué)版)
- 計(jì)算機(jī)應(yīng)用基礎(chǔ)案例教程(第二版)
- Learning D3.js 5 Mapping(Second Edition)