So far, all singleton instances are created/loaded from service.yml and this file is pre-defined before server startup. What if someone wanted to inject a bean into the service map directly in the code? This is particularly useful during testing as you can switch beans or implementations as you wish at anytime during the execution. It is however very hard for people to reason about in the production code, so it is definitely not recommended to be used in this specific scenario. Read More »

The above use cases are about interface implementation and how to bind the implementation to one or more interfaces. How about normal Java Beans? For example, what if there is a Java Bean and we want to create a singleton instance that can be shared within the JVM? What to do in the service module? Furthermore, some Java Beans have complicated initialization logic, so where do we put the logic in? Read More »

The service module is very flexible and powerful as you can combine all the above use cases together to create composite use cases. Take a look at the generated service.yml from our light-codegen and you an see that we are using it to inject plugins in many places. There are a lot more test cases in service module. It is a good place to start to learn it. Read More »

We are now dealing with constructor injection. So far all our implementations have a default constructor without any parameters. What if there are implementations with parameters in the constructor? This tutorial will show you how to do it. Also, the service module supports constructor parameters to be injected as well. You just need to make sure that parameters are injected early in the service.yml file. Here is an interface. public interface G { String getName(); void setName(String name); int getAge(); void setAge(int age); } And implementation Read More »

This is an complex use case that you have multiple interfaces and multiple implementations. It is a rare use case but we need to know how to handle it. Let’s write two interfaces. public interface E { String e(); } public interface F { String f(); } Now let’s write two implementations. public class EF1Impl implements E, F { @Override public String e() { return "e1"; } @Override public String f() { return "f1"; } } public class EF2Impl implements E, F { @Override public String e() { return "e2"; } @Override public String f() { return "f2"; } } Write a service. Read More »

This is a use case in which we have multiple interfaces but only need to load one implementation during runtime. Here are two interfaces. public interface D1 { String d1(); } public interface D2 { String d2(); } And here is an implementation. public class DImpl implements D1, D2 { @Override public String d1() { return "d1"; } @Override public String d2() { return "d2"; } } Now we need to have a service. Read More »

Sometimes, we have an interface with generic types, i.e. Validatorwhich Type is an model that will be validated. There might be a lot of different models that need to be validated in runtime. And we need to find the right instance of the validator that match to the exact model type. Let’s say we have this interface. public interface Validator<T> { boolean validate(T object); } Here is an abstract class that implements the interface. Read More »

This is a use case where you have an interface, and multiple implementations will all be used during runtime. For example, in light-4j framework, we have multiple StartupHookProviders to be loaded during server startup and execute them one by one. Also, all our middleware handlers are wired into the request/response chain the same way. Let’s say we have this interface. public interface Processor { String process(); } And we have the following three implementations want to be executed in sequence. Read More »

This is a very common use case that you have an interface and during runtime, you want to inject one and only one instance of implementation. Let’s say here is an interface. public interface A { String a(); } And we have an implementation like this. public class AImpl implements A { @Override public String a() { return "a real"; } } Now we need to put service.yml in src/main/resources/config folder. Read More »

The light-4j service module is a singleton service factory which is an IoC service to allow developers and operators to switch implementations of a specific interface in service.yml config file. You can have two implementations for one interface and two service.yml file in both main and test folder to use one instance for release and another instance for testing. Or, you can have a debug implementation in your service and enable it on production when something is wrong, or switch two different data sources on the fly. Read More »