anchor.diff:  }
   ----
   
  -The factory contains configuration property declarations, as well as public setters for these properties (You can create getters as well. It is not strictly required, but may be useful for unit tests, etc.). Now let's take a look at the Module class:
  +The factory contains configuration property declarations, as well as public setters for these properties. (You may
  +create getters as well. It is not required, but may be useful for unit tests, etc.). Now let's take a look at the
  +Module class:
   
   [source,java]
   ----
   public class MyModule extends ConfigModule {
  +
  +    @Singleton
       @Provides
       public MyService createMyService(
                ConfigurationFactory configFactory,
  -             SomeOtherService soService) {
  -
  -        return configFactory
  -                 .config(MyFactory.class, configPrefix)
  -                 .createMyService(soService);
  -    }
  -}
  -----
  -
  -And now a sample configuration that will work with our module:
  +             SomeOtherService service) {
  +
  +        return config(MyFactory.class, configFactory).createMyService(service);
  +    }
  +}
  +----
  +
  +A sample configuration that will work with our module may look like this:
   
   [source,yaml]
   ----
  
positive.code: 
  A few points to note here:
  
  * Calling our module "MyModule" and extending from `ConfigModule` gives it access to the protected "configPrefix" instance variable that is initialized to the value of "my" (the naming convention here is to use the Module simple class name without the "Module" suffix and converted to lowercase).
  * `@Provides` annotation is a Guice way of marking a Module method as a "provider" for a certain type of injectable service. All its parameters are themselves injectable objects.
  * `ConfigurationFactory` is the class used to bind a subtree of the app YAML configuration to a given Java object (in our case - MyFactory). The structure of MyFactory is very simple here, but it can be as complex as needed, containing nested objects, arrays, maps, etc. Internally Bootique uses http://wiki.fasterxml.com/JacksonHome[Jackson framework] to bind YAML to a Java class, so all the features of Jackson can be used to craft configuration.
  
  ==== Configuration File Loading
  
  There are a number of ways to pass a config file to a Bootique app, roughly falling in two categories - files contributed via DI and files passed on command line. Let's discuss them one by one:
  
  * Contributing a config file via DI:
  +
  
negative.code: BQCoreModule.extend(binder).addConfig("classpath:com/foo/default.yml");
  ----
  +
  A primary motivation for this style is to provide application default configuration, with YAML files often embedded in
  the app and read from the classpath (as suggested by the "classpath:.." URL in the example). More then one configuration
  can be contributed. E.g. individual modules might load their own defaults. Multiple configs are combined in a single
  config tree by the runtime. The order in which this combination happens is undefined, so make sure there are no conflicts
  between them. If there are, consider replacing multiple conflicting configs with a single config.
  
  * Conditionally contributing a config file via DI. It is possible to make DI configuration inclusion conditional on the
  presence of a certain command line option:
  +
  [source,java]
  ----
  