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. 

I'd favour a compile-time framework like Avaje. Avaje promises to be better suited for pure backend JSE projects than Dagger. Here's a tutorial.

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