71.8 Customize ViewResolvers
A ViewResolver
is a core component of Spring MVC, translating view names in @Controller
to actual View
implementations. Note that ViewResolvers
are mainly 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 are adding 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
with bean id ‘defaultViewResolver’. This one locates physical resources that can be rendered using theDefaultServlet
(e.g. static resources and JSP pages if you are using 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 (defaults are both empty, but accessible for external configuration viaspring.mvc.view.prefix
andspring.mvc.view.suffix
). It can be overridden by providing a bean of the same type. - A
BeanNameViewResolver
with id ‘beanNameViewResolver’. This is a useful member of the view resolver chain and will pick up any beans with the same name as theView
being resolved. It shouldn’t be necessary to override or replace it. - A
ContentNegotiatingViewResolver
with id ‘viewResolver’ is only added if there are actually beans of typeView
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 blog aboutContentNegotiatingViewResolver
that you might like to study to learn more, and also look at the source code for detail. You can switch off the auto-configuredContentNegotiatingViewResolver
by defining a bean named ‘viewResolver’. - If you use Thymeleaf you will also have a
ThymeleafViewResolver
with id ‘thymeleafViewResolver’. It looks for resources by surrounding the view name with a prefix and suffix (externalized tospring.thymeleaf.prefix
andspring.thymeleaf.suffix
, defaults ‘classpath:/templates/’ and ‘.html’ respectively). It can be overridden by providing a bean of the same name. - If you use FreeMarker you will also have a
FreeMarkerViewResolver
with id ‘freeMarkerViewResolver’. It looks for resources in a loader path (externalized tospring.freemarker.templateLoaderPath
, default ‘classpath:/templates/’) by surrounding the view name with a prefix and suffix (externalized tospring.freemarker.prefix
andspring.freemarker.suffix
, with empty and ‘.ftl’ defaults respectively). It can be overridden by providing a bean of the same name. - If you use Groovy templates (actually if groovy-templates is on your classpath) you will also have a
GroovyMarkupViewResolver
with id ‘groovyMarkupViewResolver’. It looks for resources in a loader path by surrounding the view name with a prefix and suffix (externalized tospring.groovy.template.prefix
andspring.groovy.template.suffix
, defaults ‘classpath:/templates/’ and ‘.tpl’ respectively). It can be overridden by providing a bean of the same name. - If you use Velocity you will also have a
VelocityViewResolver
with id ‘velocityViewResolver’. It looks for resources in a loader path (externalized tospring.velocity.resourceLoaderPath
, default ‘classpath:/templates/’) by surrounding the view name with a prefix and suffix (externalized tospring.velocity.prefix
andspring.velocity.suffix
, with empty and ‘.vm’ defaults respectively). It can be overridden by providing a bean of the same name.
Check out WebMvcAutoConfiguration
, ThymeleafAutoConfiguration
, FreeMarkerAutoConfiguration
, GroovyTemplateAutoConfiguration
and VelocityAutoConfiguration