You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Status

Current state: Under Discussion

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

JIRA: Unable to render Jira issues macro, execution error.

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 Unable to render Jira issues macro, execution error. , Unable to render Jira issues macro, execution error. ).

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