cryostatio/cryostat-agent

[Question] Drop Dagger DI?

andrewazores opened this issue · 4 comments

Currently we use Dagger for dependency injection in the Agent and in the main Cryostat 2.x line. Other Cryostat components - cryostat-reports and jfr-datasource - are Quarkus-based and therefore use Quarkus ArC.

Since Cryostat 3 is also Quarkus-based, the Agent will be our only consumer of Dagger. This has some downstream maintenance burden, so we should consider alternatives that have less maintenance burden.

  1. Try to use Quarkus ArC as well. It's not clear to me at this point how easy this is to actually use without being built with Quarkus to begin with.
  2. Find another DI library/framework similar to Dagger, but with a simpler build toolchain, fewer dependencies, etc. One option that came up in a cursory search was https://github.com/avaje/avaje-inject . Ideally this would be some other compile time, code generation based and lightweight system, not a heavyweight reflection system, to keep Agent resource footprint small and startup fast.

https://quarkus.io/blog/on-the-road-to-cdi-compatibility/

https://dev.to/nutrymaco/using-arc-outside-quarkus-3pep

It looks like it might be feasible to use Quarkus ArC 3.2+ (Cryostat 3.0 will also release using Quarkus 3.2.x) as a CDI-Lite DI system to replace Dagger, with just a little bit of extra work to enable the annotation processing.

After a little more reading in depth there, this would entail creating a Maven plugin to do the annotation processing and bootstrapping the ArC process of generating classes. I'm not sure it's worth the burden of creating and maintaining that plugin when we already have the Dagger setup working well enough. If an official ArC plugin becomes available in the future it would be worth switching to.

In the meantime, I think we should either stick with the Dagger status quo, or else consider switching to Avaje-inject. The build process for Avaje looks simpler than for Dagger, however it is a much smaller project that is less proven and has fewer eyeballs on it.

Another benefit to dropping Dagger in favour of ArC (or any other CDI implementation) is that SmallRye Config has a CDI extension, which would allow us to largely remove the ConfigModule and all its explicit lookup of config property keys. We would instead be able to use injection annotations like @ConfigProperty.

Another option other than ArC: https://activej.io/inject