CDI: Investigate memory leak log for @Dependent scoped beans

Problem

The test output shows logs on WARN like the following:

2021-07-29 13:37:58,044 WARNING [org.cam.bpm.eng.cdi.imp.uti.ProgrammaticBeanLookup] (main) Obtained instance of @Dependent scoped bean org.camunda.bpm.engine.cdi.BusinessProcess_Bean@2619bebc outside of process engine command context. Bean instance will not be destroyed. This is likely to create a memory leak. Please use a normal scope like @ApplicationScoped for this bean.

Reasoning

Beans defined with the scope @Dependent are associated with the enclosing bean. For instance, if there is an @ApplicationScoped bean that injects an @Dependent scoped bean, the latter is only destroyed when the former is destroyed. An @ApplicationScoped bean is destroyed when the application is undeployed. @Dependent scoped beans are prevented from garbage collection as long as the enclosing bean is not destroyed. This can lead to memory leaks, e.g., when the @Dependent scoped bean instance is not cached. If caching is not the preferred way to avoid memory leaks, CDI 1.1 has introduced new APIs to destroy beans eagerly.

The engine-cdi module takes care of destroying @Dependent scoped beans as long as a bean instance is created inside a command context. @Dependent scoped beans that are created outside the command context might lead to memory leaks, and this is why the aforementioned log entry is written.

In our engine-cdi test suite, many tests create @Dependent scoped beans outside the command context via ProgrammaticBeanLookup to perform assertions on these beans.

Conclusion

• We can ignore the logs since they are produced due to the design of the test suite.
• They occur not only in the Quarkus test suite but also in the Weld one.

Decision

In the Quarkus test suite, let's eagerly destroy the @Dependent scoped beans created outside the command context. This would likely reduce the memory consumption of the test suite.