Advanced Features

Dependency Pruning

distage performs pruning of all unused bindings by default. When you configure a set of “root” keys - either explicitly by passing Roots or implicitly by using Injector#produceRun or Injector#produceGet methods, distage will remove all bindings that aren’t required to create the supplied roots – these bindings will be thrown out and not even considered, much less executed.

Pruning serves two important purposes:

  • It enables faster tests by omitting unused instantiations and allocations of potentially heavy resources,
  • It enables multiple independent applications, aka “Roles” to be hosted within a single binary.

Example:

import distage.{Roots, ModuleDef, Injector}

class A(b: B) {
  println("A!")
}
class B() {
  println("B!")
}
class C() {
  println("C!")
}

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

// create an object graph from description in `module`
// with `A` as the GC root

val objects = Injector().produce(module, Roots.target[A]).unsafeGet()
// B!
// A!
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@1090632f

// A and B are in the object graph

objects.find[A]
// res1: Option[A] = Some(repl.MdocSession$App0$A@26a5e865)

objects.find[B]
// res2: Option[B] = Some(repl.MdocSession$App0$B@35bf6e85)

// C is missing

objects.find[C]
// res3: Option[C] = None

Class C was removed because neither B nor A depended on it. It’s neither present in the Locator nor the "C!" message from it’s constructor was ever printed.

If you add c: C parameter to class B , like class B(c: C) - then C will be instantiated, because A - the “root”, will now depend on B, and B will depend on C.

class B(c: C) {
  println("B!")
}

val objects = Injector().produce(module, Roots.target[A]).unsafeGet()
// C!
// B!
// A!
// objects: izumi.fundamentals.platform.functional.package.Identity[Locator] = izumi.distage.LocatorDefaultImpl@7fb641a0

objects.find[C]
// res5: Option[C] = Some(repl.MdocSession$App4$C@74bdd6fd)

Circular Dependencies Support

distage automatically resolves arbitrary circular dependencies, including self-references:

import distage.{DIKey, Roots, ModuleDef, Injector}

class A(val b: B)
class B(val a: A)  
class C(val c: C)

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

val objects = Injector().produce(module, Roots(DIKey[A], DIKey[C])).unsafeGet()
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@7dd2fecf

objects.get[A] eq objects.get[B].a
// res7: Boolean = true

objects.get[B] eq objects.get[A].b
// res8: Boolean = true

objects.get[C] eq objects.get[C].c
// res9: Boolean = true

Automatic Resolution with generated proxies

The above strategy depends on distage-core-proxy-cglib module and is enabled by default.

If you want to disable it, use NoProxies bootstrap configuration:

Injector.NoProxies()
// res10: Injector[izumi.fundamentals.platform.functional.package.Identity] = izumi.distage.InjectorDefaultImpl@33d76cb6

Proxies are not supported on Scala.js.

Manual Resolution with by-name parameters

Most cycles can be resolved without proxies, using By-Name parameters:

import distage.{DIKey, Roots, ModuleDef, Injector}

class A(b0: => B) {
  def b: B = b0
}

class B(a0: => A) {
  def a: A = a0
}

class C(self: => C) {
  def c: C = self
}

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

// disable proxies and execute the module

val locator = Injector.NoProxies()
  .produce(module, Roots(DIKey[A], DIKey[C]))
  .unsafeGet()
// locator: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@7ea1902d

locator.get[A].b eq locator.get[B]
// res12: Boolean = true

locator.get[B].a eq locator.get[A]
// res13: Boolean = true

locator.get[C].c eq locator.get[C]
// res14: Boolean = true

The proxy generation via cglib is enabled by default, because in scenarios with extreme late-binding cycles can emerge unexpectedly, out of control of the origin module.

Note: Currently a limitation applies to by-names - ALL dependencies of a class engaged in a by-name circular dependency must be by-name, otherwise distage will revert to generating proxies.

Weak Sets

Set bindings can contain weak references. References designated as weak will be retained only if there are other dependencies on the referred bindings, NOT if there’s a dependency only on the entire Set.

Example:

import distage.{Roots, ModuleDef, Injector}

sealed trait Elem

final case class Strong() extends Elem {
  println("Strong constructed")
}

final case class Weak() extends Elem {
  println("Weak constructed")
}

def module = new ModuleDef {
  make[Strong]
  make[Weak]
  
  many[Elem]
    .ref[Strong]
    .weak[Weak]
}

// Designate Set[Elem] as the garbage collection root,
// everything that Set[Elem] does not strongly depend on will be garbage collected
// and will not be constructed. 

val roots = Roots.target[Set[Elem]]
// roots: Roots = Of(NonEmptySet({type.scala.collection.immutable.Set[=MdocSession::App15::Elem]}))

val objects = Injector().produce(module, roots).unsafeGet()
// Strong constructed
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@2300c2c7

// Strong is around

objects.find[Strong]
// res16: Option[Strong] = Some(Strong())

// Weak is not

objects.find[Strong]
// res17: Option[Strong] = Some(Strong())

// There's only Strong in the Set

objects.get[Set[Elem]]
// res18: Set[Elem] = Set(Strong())

The Weak class was not required by any dependency of Set[Elem], so it was pruned. The Strong class remained, because the reference to it was strong, so it was counted as a dependency of Set[Elem].

If we change Strong to depend on the Weak, then Weak will be retained:

final class Strong(weak: Weak) extends Elem {
  println("Strong constructed")
}

val objects = Injector().produce(module, roots).unsafeGet()
// Weak constructed
// Strong constructed
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@4a529c32

// Weak is around

objects.find[Weak]
// res20: Option[Weak] = Some(repl.MdocSession$App19$Weak@5fba68a8)

// both Strong and Weak are in the Set

objects.get[Set[Elem]]
// res21: Set[Elem] = Set(repl.MdocSession$App19$Weak@5fba68a8, repl.MdocSession$App19$Strong@57934586)

Auto-Sets

AutoSet Planner Hooks can traverse the plan and collect all future objects that match a predicate.

Using Auto-Sets you can e.g. collect all AutoCloseable classes and .close() them after the application has finished work. NOTE: please use Resource bindings for real lifecycle, this is just an example.

import distage.{BootstrapModuleDef, ModuleDef, Injector}
import izumi.distage.model.planning.PlanningHook
import izumi.distage.planning.AutoSetHook

class PrintResource(name: String) {
  def start(): Unit = println(s"$name started")
  def stop(): Unit = println(s"$name stopped")
}

class A extends PrintResource("A")
class B(val a: A) extends PrintResource("B")
class C(val b: B) extends PrintResource("C")

def bootstrapModule = new BootstrapModuleDef {
  many[PlanningHook]
    .add(new AutoSetHook[PrintResource, PrintResource])
}

def appModule = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

val resources = Injector(bootstrapModule)
  .produceGet[Set[PrintResource]](appModule)
  .use(set => set)
// resources: izumi.fundamentals.platform.functional.package.Identity[Set[PrintResource]] = Set()

resources.foreach(_.start())
resources.toSeq.reverse.foreach(_.stop())

Calling .foreach on an auto-set is safe; the actions will be executed in order of dependencies - Auto-Sets preserve ordering, unlike user-defined Sets

e.g. If C depends on B depends on A, autoset order is: A, B, C, to start call: A, B, C, to close call: C, B, A. When using an auto-set for finalization, you must .reverse the autoset.

Note: Auto-Sets are assembled after Garbage Collection, they are assembled after garbage collection is done, as such they can’t contain garbage by construction. Because of that they also cannot be used as GC Roots.

Further reading:

Depending on Locator

Objects can depend on the outer object graph that contains them (Locator), by including a LocatorRef parameter:

import distage.{DIKey, ModuleDef, LocatorRef, Injector, Roots}

class A(
  objects: LocatorRef
) {
  def c = objects.get.get[C]
}
class B
class C

def module = new ModuleDef {
  make[A]
  make[B]
  make[C]
}

val objects = Injector().produce(module, Roots(DIKey[A], DIKey[B], DIKey[C])).unsafeGet()
// objects: izumi.fundamentals.platform.functional.package.Identity[izumi.distage.model.Locator] = izumi.distage.LocatorDefaultImpl@5d4263b1

// A took C from the object graph

objects.get[A].c
// res26: C = repl.MdocSession$App25$C@577f894c

// this C is the same C as in this `objects` value

val thisC = objects.get[C]
// thisC: C = repl.MdocSession$App25$C@577f894c

val thatC = objects.get[A].c
// thatC: C = repl.MdocSession$App25$C@577f894c

assert(thisC == thatC)

Locator contains metadata about the plan and the bindings from which it was ultimately created:

import distage.{OrderedPlan, ModuleBase}

// Plan that created this locator (after GC)

val plan: OrderedPlan = objects.plan
// plan: OrderedPlan = 
// {type.LocatorRef} (advanced-features.md:347) := import {type.izumi.distage.model.recursive.LocatorRef} // required for {type.MdocSession::App25::A}
// {type.MdocSession::App25::C} (advanced-features.md:349) := call(π:Class(): MdocSession::App25::C) {}
// {type.MdocSession::App25::B} (advanced-features.md:348) := call(π:Class(): MdocSession::App25::B) {}
// {type.MdocSession::App25::A} (advanced-features.md:347) := call(π:Class(LocatorRef): MdocSession::App25::A) {
//   arg objects: LocatorRef = lookup({type.LocatorRef})
// }

// Bindings from which the Plan was built (after GC)

val bindings: ModuleBase = plan.definition
// bindings: ModuleBase = 
// make[{type.repl.MdocSession::repl.MdocSession.App25::repl.MdocSession.App25.C}].from(call(π:Class(): repl.MdocSession::repl.MdocSession.App25::repl.MdocSession.App25.C)) ((advanced-features.md:349))
// make[{type.repl.MdocSession::repl.MdocSession.App25::repl.MdocSession.App25.B}].from(call(π:Class(): repl.MdocSession::repl.MdocSession.App25::repl.MdocSession.App25.B)) ((advanced-features.md:348))
// make[{type.repl.MdocSession::repl.MdocSession.App25::repl.MdocSession.App25.A}].from(call(π:Class(izumi.distage.model.recursive.LocatorRef): repl.MdocSession::repl.MdocSession.App25::repl.MdocSession.App25.A)) ((advanced-features.md:347))

Injector inheritance

You may run a new planning cycle, inheriting the instances from an existing Locator into your new object subgraph:

val childInjector = Injector.inherit(objects)
// childInjector: Injector[izumi.fundamentals.platform.functional.package.Identity[A]] = izumi.distage.InjectorDefaultImpl@4a4152f

class Printer(a: A, b: B, c: C) {
  def printEm() = 
    println(s"I've got A=$a, B=$b, C=$c, all here!")
}

childInjector.produceRun(new ModuleDef { make[Printer] }) {
  (_: Printer).printEm()
}
// I've got A=repl.MdocSession$App25$A@7ac90e3d, B=repl.MdocSession$App25$B@3b5e3aa0, C=repl.MdocSession$App25$C@577f894c, all here!
// res28: izumi.fundamentals.platform.functional.package.Identity[Unit] = ()

Bootloader

The plan and bindings in Locator are saved in the state they were AFTER Garbage Collection has been performed. Objects can request the original input via a PlannerInput parameter:

import distage.{Roots, ModuleDef, PlannerInput, Injector, Activation}

class InjectionInfo(val plannerInput: PlannerInput)

def module = new ModuleDef {
  make[InjectionInfo]
}

val input = PlannerInput(module, Activation.empty, Roots.target[InjectionInfo])
// input: PlannerInput = PlannerInput(
// make[{type.repl.MdocSession::repl.MdocSession.App29::repl.MdocSession.App29.InjectionInfo}].from(call(π:Class(izumi.distage.model.PlannerInput): repl.MdocSession::repl.MdocSession.App29::repl.MdocSession.App29.InjectionInfo)) ((advanced-features.md:410)),Activation(Map()),Of(NonEmptySet({type.repl.MdocSession::repl.MdocSession.App29::repl.MdocSession.App29.InjectionInfo})))

val injectionInfo = Injector().produce(input).unsafeGet().get[InjectionInfo]
// injectionInfo: InjectionInfo = repl.MdocSession$App29$InjectionInfo@3c3cf95a

// the PlannerInput in `InjectionInfo` is the same as `input`

assert(injectionInfo.plannerInput == input)

Bootloader is another summonable parameter that contains the above information in aggregate and lets you create another object graph from the same inputs as the current or with alterations.

Inner Classes and Path-Dependent Types

Path-dependent types with a value prefix will be instantiated normally:

import distage.{Roots, ModuleDef, Injector}

class Path {
  class A
}
val path = new Path
// path: Path = repl.MdocSession$App31$Path@66adc7c0

def module = new ModuleDef {
  make[path.A]
}

Injector()
  .produce(module, Roots.Everything)
  .use(_.get[path.A])
// res32: izumi.fundamentals.platform.functional.package.Identity[path.A] = repl.MdocSession$App31$Path$A@32bc7be7

Since version 0.10, support for types with a non-value prefix (type projections) has been dropped.

However, there’s a gotcha with value prefixes, when seen by distage they’re based on the literal variable name of the prefix, not the full type information available to the compiler, therefore the following usage, a simple rename, will fail:

def pathModule(p: Path) = new ModuleDef {
  make[p.A]
}

val path1 = new Path
// path1: Path = repl.MdocSession$App31$Path@16950df2
val path2 = new Path
// path2: Path = repl.MdocSession$App31$Path@4db8c053
Try {
  Injector().produceRun(pathModule(path1) ++ pathModule(path2)) {
    (p1a: path1.A, p2a: path2.A) =>
      println((p1a, p2a))
  }
}.isFailure
// res33: Boolean = true

This will fail because while path1.A and p.A inside new ModuleDef are the same type as far as Scala is concerned, the variables path1 & p are spelled differently and this causes a mismatch in distage.

There’s one way to workaround this - turn the type member A into a type parameter using the Aux Pattern, and then for that type parameter in turn, summon the type information using Tag implicit (as described in Tagless Final Style chapter) and summon the constructor using the ClassConstructor implicit, example:

import distage.{ClassConstructor, ModuleDef, Injector, Tag}

object Path {
  type Aux[A0] = Path { type A = A0 }
}

def pathModule[A: Tag: ClassConstructor](p: Path.Aux[A]) = new ModuleDef {
  make[A]
}

val path1 = new Path
// path1: Path = repl.MdocSession$App34$Path@45a39de3
val path2 = new Path
// path2: Path = repl.MdocSession$App34$Path@1491a5f3

Injector().produceRun(pathModule(path1) ++ pathModule(path2)) {
  (p1a: path1.A, p2a: path2.A) =>
    println((p1a, p2a))
}
// (repl.MdocSession$App34$Path$A@45f613de,repl.MdocSession$App34$Path$A@2f4fb568)
// res35: izumi.fundamentals.platform.functional.package.Identity[Unit] = ()

Now the example works, because the A type inside pathModule(path1) is path1.A and for pathModule(path2) it’s path2.A, which matches their subsequent spelling in (p1a: path1.A, p2a: path2.A) => in produceRun