Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Drop Dagger DI? #294

Open
andrewazores opened this issue Dec 6, 2023 · 4 comments
Open

[Question] Drop Dagger DI? #294

andrewazores opened this issue Dec 6, 2023 · 4 comments
Labels
chore Refactor, rename, cleanup, etc. question Further information is requested

Comments

@andrewazores
Copy link
Member

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.
@andrewazores andrewazores added chore Refactor, rename, cleanup, etc. question Further information is requested labels Dec 6, 2023
@andrewazores
Copy link
Member Author

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.

@andrewazores
Copy link
Member Author

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.

@andrewazores
Copy link
Member Author

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.

@andrewazores
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Refactor, rename, cleanup, etc. question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant