anchor.diff:  	</web-app>
   ----
   
  -In this example we are using a single application context (the one created by the context
  -listener) and attaching it to the `DispatcherServlet` using an init parameter. This is
  +In the preceding example, we use a single application context (the one created by the context
  +listener) and attach it to the `DispatcherServlet` by using an `init` parameter. This is
   normal in a Spring Boot application (you normally only have one application context).
   
   
   
   [[howto-use-jedis-instead-of-lettuce]]
  -=== Use Jedis instead of Lettuce
  -The Spring Boot starter (`spring-boot-starter-data-redis`) uses
  -https://github.com/lettuce-io/lettuce-core/[Lettuce] by default. You need to exclude that
  +=== Use Jedis Instead of Lettuce
  +By default, the Spring Boot starter (`spring-boot-starter-data-redis`) uses
  +https://github.com/lettuce-io/lettuce-core/[Lettuce]. You need to exclude that
   dependency and include the https://github.com/xetorthio/jedis/[Jedis] one instead. Spring
   Boot manages these dependencies to help make this process as easy as possible.
   
  -Example in Maven:
  +The following example shows how to do so in Maven:
   
   [source,xml,indent=0,subs="verbatim,quotes,attributes"]
   ----
  
positive.code: 	logging.level.org.hibernate=ERROR
  ----
  
  You can also set the location of a file to log to (in addition to the console) using
  "logging.file".
  
  To configure the more fine-grained settings of a logging system you need to use the native
  configuration format supported by the `LoggingSystem` in question. By default Spring Boot
  picks up the native configuration from its default location for the system (e.g.
  `classpath:logback.xml` for Logback), but you can set the location of the config file
  using the "logging.config" property.
  
  
  
  [[howto-configure-logback-for-logging]]
  === Configure Logback for logging
  If you put a `logback.xml` in the root of your classpath it will be picked up from
  there
  (or `logback-spring.xml` to take advantage of the templating features provided by Boot).
  Spring Boot provides a default base configuration that you can include if you just
  want to set levels, e.g.
  
  [source,xml,indent=0,subs="verbatim,quotes,attributes"]
  ----
  
negative.code: used in UI applications, rather than REST-style services (a `View` is not used to render
  a `@ResponseBody`). There are many implementations of `ViewResolver` to choose from, and
  Spring on its own is not opinionated about which ones you should use. Spring Boot, on the
  other hand, installs one or two for you, depending on what it finds on the classpath and
  in the application context. The `DispatcherServlet` uses all the resolvers it finds in
  the application context, trying each one in turn until it gets a result, so, if you
  add your own, you have to be aware of the order and in which position your resolver is
  added.
  
  `WebMvcAutoConfiguration` adds the following `ViewResolvers` to your context:
  
  * An `InternalResourceViewResolver` named '`defaultViewResolver`'. This one locates
    physical resources that can be rendered by using the `DefaultServlet` (including static
    resources and JSP pages, if you use those). It applies a prefix and a suffix to the
    view name and then looks for a physical resource with that path in the servlet context
    (the defaults are both empty but are accessible for external configuration through
    `spring.mvc.view.prefix` and `spring.mvc.view.suffix`). You can override it by
  	providing a bean of the same type.
  * A `BeanNameViewResolver` named '`beanNameViewResolver`'. This is a useful member of the
    view resolver chain and picks up any beans with the same name as the `View` being
    resolved. It should not be necessary to override or replace it.
  * A `ContentNegotiatingViewResolver` named '`viewResolver`' is added only if there *are*
    actually beans of type `View` present. This is a '`master`' resolver, delegating to all
    the others and attempting to find a match to the '`Accept`' HTTP header sent by the
    client. There is a useful
    https://spring.io/blog/2013/06/03/content-negotiation-using-views[blog about `ContentNegotiatingViewResolver`]
    that you might like to study to learn more, and you might also look at the source code
  	for detail. You can switch off the auto-configured `ContentNegotiatingViewResolver` by
  	defining a bean named '`viewResolver`'.
  * If you use Thymeleaf, you also have a `ThymeleafViewResolver` named
    '`thymeleafViewResolver`'. It looks for resources by surrounding the view name with a
    prefix and suffix. The prefix is `spring.thymeleaf.prefix`, and the suffix is
    `spring.thymeleaf.suffix`. The values of the prefix and suffix default to
  	'`classpath:/templates/`' and '`.html`', respectively. You can override
  	`ThymeleafViewResolver` by providing a bean of the same name.
  * If you use FreeMarker, you also have a `FreeMarkerViewResolver` named
    '`freeMarkerViewResolver`'. It looks for resources in a loader path (which is
  	externalized to `spring.freemarker.templateLoaderPath` and has a default value of
  	'`classpath:/templates/`') by surrounding the view name with a prefix and suffix. The
  	prefix is externalized to `spring.freemarker.prefix`, and the suffix is externalized to
  	`spring.freemarker.suffix`. The default values of the prefix and suffix are empty and
  	'`.ftl`', respectively. You can override `FreeMarkerViewResolver` by providing a bean
  	of the same name.
  * If you use Groovy templates (actually, if `groovy-templates` is on your classpath), you
    also have a `GroovyMarkupViewResolver` named '`groovyMarkupViewResolver`'. It looks for
  	resources in a loader path by surrounding the view name with a prefix and suffix
  	(externalized to `spring.groovy.template.prefix` and `spring.groovy.template.suffix`).
  	The prefix and suffix have default values of '`classpath:/templates/`' and '`.tpl`',
    respectively. You can override `GroovyMarkupViewResolver` by providing a bean of the
  	same name.
  
  For more detail, see the following sections:
  
  * {sc-spring-boot-autoconfigure}/web/servlet/WebMvcAutoConfiguration.{sc-ext}[`WebMvcAutoConfiguration`]
  * {sc-spring-boot-autoconfigure}/thymeleaf/ThymeleafAutoConfiguration.{sc-ext}[`ThymeleafAutoConfiguration`]
  * {sc-spring-boot-autoconfigure}/freemarker/FreeMarkerAutoConfiguration.{sc-ext}[`FreeMarkerAutoConfiguration`]
  * {sc-spring-boot-autoconfigure}/groovy/template/GroovyTemplateAutoConfiguration.{sc-ext}[`GroovyTemplateAutoConfiguration`]
  
  
  
  [[howto-http-clients]]
  == HTTP Clients
  
  Spring Boot offers a number of starters that work with HTTP clients. This section answers
  questions related to doing so.
  
  [[howto-http-clients-proxy-configuration]]
  === Configure RestTemplate to Use a Proxy
  As described in <<spring-boot-features.adoc#boot-features-resttemplate-customization>>,
  you can use a `RestTemplateCustomizer` with `RestTemplateBuilder` to build a customized
  `RestTemplate`. This is the recommended approach for creating a `RestTemplate` configured
  to use a proxy.
  
  The exact details of the proxy configuration depend on the underlying client request
  factory that is being used. The following example configures
  `HttpComponentsClientRequestFactory` with an `HttpClient` that uses a proxy for all hosts
  except `192.168.0.5`:
  
  [source,java,indent=0]
  ----
  