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: ----
  
  You can use the `apply` or `vend` method on the FactoryMaker directly,
  which will give you the instance you need. I'll be using `vend` for
  further examples just so that it is clear what is happening.
  
  Calling `DependencyFactory.sequenceNumberService.vend` will return a
  new number every time, since that is how it has been setup. This is, in
  spring terminology, https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-prototype[the prototype scope].
  
  An alternative way is to use `DependencyFactory.inject`. But it
  returns `Box` and it is only needed if don't have a FactoryMaker for a
  given dependency. Which brings us to the fact that there are other
  ways of registering dependencies apart from the FactoryMaker. For ex.
  
  
negative.code: `SessionVar` instances in general. So, there you go. Use `Inject` if
  you don't need the session/request scopes.
  
  == Lift's dependency injection and Spring's dependency scopes
  
  Lift's dependency injection easily 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], and then some!
  
  For ex. the https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-singleton[singleton scope] is achieved when
  the function (the `Vendor`) used for constructing the `FactoryMaker` or `Inject` returns the same instance every time.
  The https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html#beans-factory-scopes-prototype[prototype scope] is
  achieved when that function returns a new instance every time it is called. Request and session scopes are explained
  in the section <<Session or request scoped dependencies>>. The other scopes can be achieved relatively easily if needed.
  
  == Conclusion
  
  Most of the time, you should be able to do away with any specialized
  dependency injection framework. Lift provides powerful and flexible mechanisms for vending instances
  based on a global function, call stack scoping, request and session scoping and provides more
  flexible features than most Java-based dependency injection frameworks, without resorting to XML
  for configuration or byte-code rewriting magic.