anchor.diff:  }
   ----
   
  -However, there is a possible problem with this approach (I haven't
  -tested it). If your test suites are running in parallel, this
  -set/reset of the default instance will be problematic. I don't
  -recommend this approach unless you know what you are doing.
  +However, there is a potential problem with this approach.
  +If your test suites are running in parallel, this
  +set/reset of the default instance will be problematic. This approach is not
  +recommended unless you know what you are doing.
   
   One safe way of doing this is to use the stackable nature of the
   `Makers`:
  
positive.code: == Introduction
  
  Dependency injection is an important topic in the JVM world. With Java, we usually go with Guice
  or Spring whenever we need it. However, scala has certain advantages over Java, like functions,
  that allow basic DI without resorting to entire DI frameworks.
  
  Scala allows the use of http://jonasboner.com/real-world-scala-dependency-injection-di/[cake pattern]
  that can provide DI by composing traits.
  
  Although the cake pattern is helpful, it doesn't provide complete DI functionality.
  The cake pattern allows you to compose complex classes out of Scala traits, but it is less helpful
  in terms of allowing you to make dynamic choices about which combination of cake to vend in a given situation.
  Lift provides extra features that complete the dependency injection puzzle.
  
  == Why Lift Dependency Injection
  
  Many people come to Scala from a Java background, so it is only natural to want to use Guice/Spring,
  which do a great job in the java world. And we can https://groups.google.com/forum/#!topic/liftweb/_lleL2xpCFU[use those],
  but there's a better, more direct way that is less magical.
  
  Lift's philosophy is to keep things as simple as possible (and no simpler), and allow full control
  to the developers over how things work. To paraphrase David Pollak,
  "The abstraction turtles have to end somewhere" and  Lift's Dependency Injection features end those turtles quite
  early.
  
  == Lift's dependency injection and various dependency scopes (e.g. from Spring)
  
  Lift's dependency injection allows all the
  https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes[four most commonly used scopes] that
  are possible with spring:
  https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-singleton[singleton],
  https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-prototype[prototype], https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-request[request],
  and https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-session[session]. The others can be achieved
  relatively easily if you want.
  
  == Getting started
  
  Lift's dependency injection is based on two main traits https://liftweb.net/api/26/api/index.html#net.liftweb.util.Injector[`Injector`]
  and https://liftweb.net/api/26/api/index.html#net.liftweb.util.Maker[`Maker`]. However, most of the time, you won't need to
  deal with them directly. The elements that you would use are:
  
  . https://liftweb.net/api/26/api/index.html#net.liftweb.http.Factory[`Factory`] trait
  . https://github.com/lift/framework/blob/5033c8798d4444f81996199c10ea330770e47fbc/web/webkit/src/main/scala/net/liftweb/http/Factory.scala#L37[`FactoryMaker`], which is an abstract class inside
   inside the [`Factory`] trait.
  . https://liftweb.net/api/26/api/index.html#net.liftweb.util.SimpleInjector$Inject[`Inject`], an abstract class within the
   `SimpleInjector` trait.
  
  `FactoryMaker` and `Inject` serve the same purpose, with the former
  having more features. The difference is important. Notes on this are
  at the end. I'll continue with `FactoryMaker` for the sake of
  examples, and then note the differences between the two at the end.
  
  To start with, here's an example of how these are supposed to be
  used:
  
  [source,scala]
  ----
  
negative.code: }
  ----
  
  Now, when you do `DependencyFactory.cardService.vend`, it will use
  the `DefaultInstance`. Your call will be implicitly translated to
  `DependencyFactory.instance.vend.cardService.vend`. This is the part
  that allows you to completely override everything you need in your
  