Wrong bean scopes used in project

[dartartem]

Problem:

instead of @Produces I accidentally used @Singleton https://github.com/eventuate-tram/eventuate-tram-core-quarkus/blob/master/eventuate-tram-quarkus-in-memory/src/main/java/io/eventuate/tram/quarkus/inmemory/TramInMemoryConfiguration.java and tests passed. However, if change it to @Produces (As it is used everywhere) tests failed.

Reason:

@Produces does not mean "create bean with scope defined in class annotation" in case of TramInMemoryConfiguration - @ApplicationScoped.

It means that scope is not defined and defaulted to @Dependent (new instance each time on inject).

Point 12: https://quarkus.io/guides/cdi

So, bean definitions should be annotated with desired scope as configuration classes.

Desired behavior:

Beans should be in global scope for application.

There are 2 options (Point 10: https://quarkus.io/guides/cdi):

@javax.enterprise.context.ApplicationScoped

A single bean instance is used for the application and shared among all injection points. The instance is created lazily, i.e. once a method is invoked upon the client proxy.

@javax.inject.Singleton

Just like @ApplicationScoped except that no client proxy is used. The instance is created when an injection point that resolves to a @Singleton bean is being injected.

Currently, eventuate quarkus projects supposed to use @ApplicationScoped

However, it has a drawback that defined beans should have default constructor: https://stackoverflow.com/questions/48410451/why-do-i-need-a-no-args-constructor-to-use-applicationscoped-beans-with-construc

Not all eventuate bean classes have it.

And there are no used advantages in @ApplicationScoped (Point 11: https://quarkus.io/guides/cdi) to change them:

• Lazy instantiation - the instance is created once a method is invoked upon the proxy.
• Ability to inject a bean with "narrower" scope to a bean with "wider" scope; i.e. you can inject a @RequestScoped bean into an @ApplicationScoped bean.
• Circular dependencies in the dependency graph. Having circular dependencies is often an indication that a redesign should be considered, but sometimes it’s inevitable.
• In rare cases it’s practical to destroy the beans manually. A direct injected reference would lead to a stale bean instance.

Solution:

Use @Singleton as default scope.