Status
Current state: Under Discussion
Discussion thread: https://lists.apache.org/thread/9y2qd7rs45049xbrt0gty40m4b5cv22y
JIRA:
Released: -
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Confluence supports inline comments that can also be used.
Motivation
- Use a standardized dependency injection in Solr instead of several brittle home grown interfaces (@SolrCoreAware, @ResourceLoaderAware, @SchemaAware) that tend to not work in all situations.
- Limit huge constructors that pass instances around
- Easier code maintenance
Public Interfaces
No user-facing changes on HTTP APIs or configs.
Some plugins will change API that is not back-compat.
Proposed Changes
Too early to propose concrete design now, but start with a POC to prove the concept on a limited part of the code.
Introduce a well supported IOC/DI framework to gradually replace the home-grown interfaces which are brittle (see
, ).This will be a large change across the entire code base. The framework will scan the codebase for annotations and generate new Java code that will be used run-time.
There are several CI frameworks to choose from, and the next section details some of them.
There are several CI frameworks to choose from, see sub section "Choice of DI framework". I'd favour a compile-time framework like Avaje or Dagger2. Avaje promises to be better suited for pure backend JSE projects than Dagger.
Choice of DI framework
Here is a list stolen from a reddit thread:
- Avaje*
- Dagger 2*
- Dirk
- Feather
- Guice
- Glassfish HK2 (Solr already has limited use of this in Jersey JAX-RS)
- Inverno*
- Jaywire
- JBock*
- Spring
- Weld
Some of these use runtime reflection to build the graph, others (the ones marked with an asterisk) use compile-time code generation.
Code samples for each can be found in this repo: https://github.com/Col-E/Useful-Things/tree/master/tutorials/dependency-injection
Wrt the existing use of HK2 it can be investigated whether we can keep it in parallel with Avaje/Dagger or switch over.
Compatibility, Deprecation, and Migration Plan
- Users will not notice anything
- Developers and 3rd party plugin providers may need to re-write their plugins
- The change is breaking and should be introduced in a major version
Security considerations
None
Test Plan
Will be tested implicitly by the test suite.
Rejected Alternatives
- Spring Framework, Micronaut or other larger framework - too intrusive
- Guice and other reflection based frameworks - injection happens during runtime, hard to debug
- Continue as we do, Improve our home grown annotations