Skip to content

Bootstrapping

Randgalt edited this page Oct 17, 2012 · 25 revisions

Governator creates two Guice injectors: an internal “bootstrapping” Injector and the main application Injector. The main Injector is created when you call LifecycleInjectorBuilder.createInjector(). The bootstrapping injector is created internally by Governator.

Why Two Injectors?

Governator features introduce recursive dependencies. Configuration Mapping requires ConfigurationProvider instances. Auto Binding arguments require AutoBindProvider instances. These instances are needed as the main Injector is being created (i.e. as Guice is creating instances).

Bootstrapping Steps

Bootstrapping is part of the classpath scanning step:

  • ConfigurationProvider classes annotated with @AutoBindSingleton are detected and bound into the bootstrap Injector.
  • AutoBindProvider classes must be bound in the bootstrapping step
  • Application specific bootstrap binding is done via the specified bootstrap module (if any).

You can specify your own bootstrap bindings if needed by specifying a bootstrap module:

LifecycleInjector.builder().withBootstrapModule(yourBootstrapModule)

The bootstrap module is passed a special Guice Binder that has an additional method for binding ConfigurationProviders. Always use this special method:

  /**
   * Use this to bind {@link ConfigurationProvider}s. Do NOT use standard Guice binding.
   *
   * @return configuration binding builder
   */
  public LinkedBindingBuilder<ConfigurationProvider> bindConfigurationProvider();

LifecycleListener

You can bind a LifecycleListener in the bootstrap module. See the LifecycleListener wiki for details.

AutoBindProvider

You must bing any AutoBindProvider instances in the bootstrap module. See the Auto Binding wiki for details.

Completion

At the end of Bootstrapping, Governator creates the bootstrap injector and gets the LifecycleManager instance which manages the main injection phase. Any bound configuration providers are injected into the LifecycleManager.