Status

Current state: Under Discussion

Discussion thread: https://lists.apache.org/thread/9y2qd7rs45049xbrt0gty40m4b5cv22y

JIRA: SOLR-16998 - Getting issue details... STATUS

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 SOLR-16203 - Getting issue details... STATUS , SOLR-8311 - Getting issue details... STATUS ).

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
  • No labels