Graylog2 / Graylog2/graylog2-server
Guice modules structure makes it difficult to reuse and override for tests
- Dominant language
- Java
- Stars
- 8.1k
- Forks
- 1.1k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 217
Description
Our guice modules have grown over time and aren't well structured.
With relying on Multibinders and MapBinders more and more for extensibility, we run into odd corner cases when the binder is not created, because no plugins have contributed anything, but then binding can fail in remote locations of the code, often tests.
Unit tests have a hard time using injection, because it is very difficult to see which modules are necessary, which can be overridden and quickly mocking an entire layer is very repetitive due to manual construction.
The modules should be split up into functional groups, not per type as some legacy bindings are now, and inside of that be split by "interface modules" (i.e. the necessary multibinders) and the actual implementation used in the product. Ideally there should also be a module for binding dummies/mocks/in-memory services for use in tests.
The modules should be co-located with the code they bind, so that we don't have to hunt all over the place for the corresponding bindings. Ideally we would also unify the usage of binding annotations and explicit code bindings, to make it easier to follow, i.e. do away with binding annotations whereever possible.
Contributor guide
Assessment
This issue has not been assessed yet.