Using @Startup with @Produces methods

[julianhowarth]

Creating an @ApplicationScoped bean with a method annotated with @Startup works as described in the documentation. The instance starts even if no other classes are dependent on it, and the startup-annotated method gets called after injection is complete

However, I want to create instances of my bean via a producer method such that I get the same behaviour:

• the bean is created even when nothing depends on it
• my startup method gets called

So what I have is:

public class TestBean {

  public TestBean() {
    System.out.println("constructed");
  }

  @PostConstruct
  void init() {
    System.out.println("I'M ALIVE!");
  }
}

public class Producers {

  @Produces
  @Startup
  TestBean testBean() {
    System.out.println("constructing");
    return new TestBean();
  }
}

I see messages:

constructing
constructed

but the @PostConstruct method is not getting called.

Am I misunderstanding how the @Startup works in a producer context? Or is there another way of achieving what I want?

[gsmet]

/cc @Ladicek @manovotn

[manovotn]

@PostConstruct does not work for producers, it is meant only for class-based beans and as such will not be invoked at all (this is as per specification).
Otherwise, the @Startup should eager init your bean just fine as you see from your logs.

Note that your bean does not have a scope and will therefore be @Dependent - those beans are seldom useful when eagerly initialized, did you per chance mean to have it app scoped (or singleton?).

[julianhowarth]

Understood re: making it app scoped - maybe my minimal example was to too minimal.

So I can get the bean eagerly instantiated, but what I also need is to hook its init method into the Quarkus startup. Is there any way of achieving that via the producer e.g. something I could inject into the producer method and then pass into the bean's constructor?

[manovotn]

I am not sure I understand - if you annotate the producer method with @Startup it will be triggered during the @Startup event notification.
So you can go ahead and invoke the init() method right after creating the object (within the producer method body) to perform whatever initialization you need.

  @Produces
  @Startup // the bean will be eagerly init during the @Startup
  @ApplicationScoped
  TestBean testBean() {
    System.out.println("constructing");
    TestBean myBean = new TestBean();
    myBean.init();
    return myBean;
  }

[julianhowarth]

ok, let me first check my rough understanding of what happens re: cdi and startup:

• the wiring up of instances/proxies is done by Arc - general recommendation is that constructors are simple and don't do unnecessary work (though I can't now find a reference for this) which keeps this stage fast and free from side-effects
• once wiring is complete, startup events are fired which observers can act upon (e.g. startup or postconstruct annotated). These startup observers are the correct (and safe) place to actually start doing work (e.g read assets from file system, s3, database etc).

It is because of the distinction between these 2 stages that I want to defer calling my init method to the startup stage. If this is not necessary, I wouldn't bother with the init method at all and instead just do the work inside the constructor. But if that is the case, what is the reason for the wiring/startup split as my understanding above would clearly therefore be incorrect?

[Ladicek]

I don't think you have the right mental model.

once wiring is complete

Normal scoped beans (such as @ApplicationScoped or @RequestScoped) are never injected directly. A client proxy is injected instead, which forwards invocations to the correct instance, and that instance is created lazily. So you cannot really say that "wiring is complete before startup", unless all your beans are @Singleton or @Dependent.

(Note that this depends on what you mean by "wiring", which might be different from my understanding of the term.)

startup events are fired which observers can act upon (e.g. startup or postconstruct annotated)

You cannot mix @PostConstruct callbacks and startup observers like this. There is no guarantee that they happen at the same time (although there is a guarantee that @PostConstruct callbacks are called before startup observers).

@PostConstruct is invoked immediately after an object is constructed and all its dependencies are injected. (Note that this only applies if it is the container who instantiates the bean. In case of a producer method, it is your code who instantiates the bean, so @PostConstruct is not called automatically.)

On the other hand, a startup observer is invoked when the application starts. If an @ApplicationScoped bean has a startup observer, it may be that the startup observer is the first thing that forces that bean into existence (see above). So the bean is first constructed and then the observer is called. It is not 100% guaranteed though; it may be that the bean has been forced to existence beforehand, e.g. by some other bean calling one of its methods.

If you have a producer method of a normal scoped bean, however, it all collapses into a relatively straightforward answer: it doesn't matter if you initialize everything in a constructor or a method called from the producer right after instantiation. It all happens at the same time.

[julianhowarth]

ok, thanks for the explanation, along with the bonus that my code can be simpler.

Just out of curiosity, for @ApplicationScoped beans was my understanding of what the startup observer should be used for correct?

These startup observers are the correct (and safe) place to actually start doing work (e.g read assets from file system, s3, database etc)

Or is their intended use for something different - the documentation doesn't make it clear why you might want to use them, and I may well have made incorrect assumptions.

[manovotn]

So the @Startup is meant to be an indication of readiness of your application/container. I.e. the earliest point in which you can perform certain task before, say, requests start coming in.

Apart from Quarkus docs, it is now also part of the CDI specification which states:

This event can be observed by integrators and libraries to perform any kind of early initialization as well as by users as a reliable entry point for when the CDI container is ready.

There are two uses, really:

• You want your bean to eagerly initialize as soon as possible (typically useful for app scoped beans)
  • For this you can use this observer even empty, or use some internal logic inside the bean to do after-init steps
  • A use case I can think of is that the bean init might be costly and you want to make sure the instance is up and running before any other traffic starts. Without it, it would initialize on first use which is the lazy init Ladislav mentioned.
• You want to perform some application logic that can only be performed at runtime and needs to happen as soon as the app starts and before any requests (or other handling) happens.
  • The observer will make sure to initialize the bean as soon as possible and you can then execute the logic you need. You can further specify @Priority to make sure you run even before other startup observers the app might have.