The Lifecycle Objects on CDI [Video]

When we talk about a system OOP, we naturally, work with objects: those objects exist in memory until you destroy them. Object lifecycle routines allow the creation and destruction of object references.

In enterprise system architecture design, we can imagine several cases, such as a @Connection instance, where when we create an instance, need to open the connection, and then don't need this instance. We can close and then destroy it.

Lifecycle methods associated with an object will enable you to control what happens when an object is created or destroyed. We can break the life of an object into three phases: start, usage, and trashing. 

CDI allows you to create and handle objects. By default, CDI will create an instance using the constructor; however, sometimes, there is no reason for it. Therefore, we have the @Vetoed annotation to teach CDI not to use this way.

@Vetoed
public class Music {

    private String sing;

    Music() {
    }

    public Music(String sing) {
        this.sing = sing;
    }

    public void play() {
        System.out.println("Playing the music: " + sing);
    }

    public void stop() {
        System.out.println("Stop sinning the music: " + sing);
    }

    @Override
    public String toString() {
        return "Music{" +
                "sing='" + sing + '\'' +
                '}';
    }
}

CDI is brilliant, and I will learn it very quickly. On the other hand, we have trouble teaching CDI to create an object in a different way. It does not make sense only with the entity that we design in the same package or project, but also with integration with libraries that already do exist.

To make it possible, CDI provides a @Produces annotation where it will explain to CDI to use this instance when someone inside the container needs it. If you are familiar with Spring, it is similar to combining two annotations inside the platform: @Bean and @Configuration.

As an object, a managed bean inside CDI, we can express the lifecycle of this object. We need to put the same CDI annotation @Scoped we learned previously on the Producer method.

• RequestScoped
• ApplicationScoped
• SessionScoped
• ConversationScoped

A good example would be a system that uses the money-API, and we want to define a currency available to the whole system. It does not make sense to the client to know which currency the system uses or where this currency comes from. It only needs to inject and then use this currency.

The solution is to explore the producer's power to make it unrestricted to the whole system.

class CurrencySupplier {

    private CurrencyUnit currency;

    @PostConstruct
    public void setUp() {
        this.currency = Monetary.getCurrency("EUR");
    }

    @Produces
    CurrencyUnit getCurrency() {
        return currency;
    }

    void close(@Disposes CurrencyUnit currency) {
        System.out.println("We don't need this currency: " + currency);
    }
}

The last step in an object's lifecycle is when it dies: e.g., when the connection or any resource needs to be closed.

CDI has the @Disposes annotation, in comparison, is the opposite of @Produces. Therefore, we use @Produces to build up and @Dispose to destroy.

This video will explain more details about the object's lifecycle with CDI, where you can take benefits of this robust framework to control objects/resources. We'll explain how to ignore beans with @Vetoed annotation and make up and destroy with @Produce and @Dispose annotations, respectively.