anchor.diff:  * Applications without a context hierarchy.
   
   All of these should be amenable to translation, but each might require slightly different
  -tricks.
  +techniques.
   
   Servlet 3.0+ applications might translate pretty easily if they already use the Spring
  -Servlet 3.0+ initializer support classes. Normally all the code from an existing
  +Servlet 3.0+ initializer support classes. Normally, all the code from an existing
   `WebApplicationInitializer` can be moved into a `SpringBootServletInitializer`. If your
  -existing application has more than one `ApplicationContext` (e.g. if it uses
  -`AbstractDispatcherServletInitializer`) then you might be able to squash all your context
  +existing application has more than one `ApplicationContext` (for example, if it uses
  +`AbstractDispatcherServletInitializer`) then you might be able to combine all your context
   sources into a single `SpringApplication`. The main complication you might encounter is if
  -that doesn't work and you need to maintain the context hierarchy. See the
  +combining does not work and you need to maintain the context hierarchy. See the
   <<howto-build-an-application-context-hierarchy, entry on building a hierarchy>> for
  -examples. An existing parent context that contains web-specific features will usually
  -need to be broken up so that all the `ServletContextAware` components are in the child
  +examples. An existing parent context that contains web-specific features usually
  +needs to be broken up so that all the `ServletContextAware` components are in the child
   context.
   
  -Applications that are not already Spring applications might be convertible to a Spring
  -Boot application, and the guidance above might help, but your mileage may vary.
  +Applications that are not already Spring applications might be convertible to Spring
  +Boot applications, and the previously mentioned guidance may help. However, you may yet
  +encounter problems. In that case, we suggest
  +https://stackoverflow.com/questions/tagged/spring-boot[asking questions on Stack Overflow
  +with a tag of `spring-boot`].
   
   
   
   [[howto-weblogic]]
   ===  Deploying a WAR to WebLogic
  -To deploy a Spring Boot application to WebLogic you must ensure that your servlet
  +To deploy a Spring Boot application to WebLogic, you must ensure that your servlet
   initializer *directly* implements `WebApplicationInitializer` (even if you extend from a
   base class that already implements it).
   
  -A typical initializer for WebLogic would be something like this:
  +A typical initializer for WebLogic should resemble the following example:
   
   [source,java,indent=0,subs="verbatim,quotes,attributes"]
   ----
  
positive.code: ----
  
  Logs are stored in a `logs` directory relative to the working directory of the
  application. This can be customized via `server.undertow.accesslog.directory`.
  
  Finally, access logging for jetty can also be configured that way:
  
  [source,properties,indent=0,subs="verbatim,quotes,attributes"]
  ----
  
negative.code: [[howto-servlet-2-5]]
  ===  Deploying a WAR in an Old (Servlet 2.5) Container
  Spring Boot uses Servlet 3.0 APIs to initialize the `ServletContext` (register `Servlets`
  and so on), so you cannot use the same application in a Servlet 2.5 container.
  It *is*, however, possible to run a Spring Boot application on an older container with some
  special tools. If you include `org.springframework.boot:spring-boot-legacy` as a
  dependency (https://github.com/scratches/spring-boot-legacy[maintained separately] to the
  core of Spring Boot and currently available at 1.0.2.RELEASE), all you should need to do
  is create a `web.xml` and declare a context listener to create the application context and
  your filters and servlets. The context listener is a special purpose one for Spring Boot,
  but the rest of it is normal for a Spring application in Servlet 2.5. The following Maven
  example shows how to set up a Spring Boot project to run in a Servlet 2.5 container:
  
  [source,xml,indent=0]
  ----
  