Spring Resolver's

Spring Boot Starter Web provides all the dependencies and the auto configuration need to develop web applications. It is the first dependency we would use.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Class UrlBasedViewResolver extends AbstractCachingViewResolver implements Ordered

View state doesn't change during the running of the application, so implementations are free to cache views.

The view class for all views generated by this resolver can be specified via UrlBasedViewResolver.setViewClass(Class<?>), .setPrefix(String), setSuffix(String)

When developing a Spring Boot project, you usually use only one technology for the View layer ( JSP, Thymeleaf, FreeMarker, ...), the Spring Boot will automatically configure a ViewResolver for you to work with that technology. However, in case you use multiple technologies for the View layer, you have to manually configure all necessary ViewResolvers.

View Resolver src/main/resources/templates | src/main/webapp/WEB-INF
  Files under WEB-INF can only accessed by controllers. So that to hide them from direct access.
	Thymeleaf - /templates/*.html
	FreeMarker- /templates/freemarker/*.html | /WEB-INF/views/freemarker/*.html
	JSP       - /WEB-INF/pages/*.jsp

InternalResourceViewResolver extends UrlBasedViewResolver

It's good practice to put JSP files that just serve as views under WEB-INF, to hide them from direct access (e.g. via a manually entered URL). Only controllers will be able to access them then.

class JstlView extends InternalResourceView

Exposes JSTL-specific request attributes specifying locale and resource bundle for JSTL's formatting and message tags, using Spring's locale and MessageSource.

Typical usage with InternalResourceViewResolver looks as follows, from the perspective of the DispatcherServlet context definition:

 <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
   <property name="prefix" value="/WEB-INF/jsp/"/>
   <property name="suffix" value=".jsp"/>
 </bean>
 <bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
   <property name="basename" value="messages"/>
 </bean>

Every view name returned from a handler will be translated to a JSP resource (for example: "myView" -> "/WEB-INF/jsp/myView.jsp"), using this view class to enable explicit JSTL support. The specified MessageSource loads messages from "messages.properties" etc files in the class path.

<!-- JSP -->
<dependency>
   <groupId>org.apache.tomcat.embed</groupId>
   <artifactId>tomcat-embed-jasper</artifactId>
</dependency>
<!-- JSTL -->
<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>jstl</artifactId>
</dependency>

Note: When chaining ViewResolvers, an InternalResourceViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.

AbstractTemplateViewResolver extends UrlBasedViewResolver

Abstract base class for template view resolvers, in particular for FreeMarker views.

AbstractTemplateView « Adapter base class for template-based view technologies such as FreeMarker, with the ability to use request and session attributes in their model and the option to expose helper objects for Spring's FreeMarker macro library.

Spring App Single View	Spring Boot App Multiple views with priority

Ordered is an interface that can be implemented by objects that should be orderable, for example in a Collection.

In case, you use multiple technologies for the View layer, a lot of ViewResolvers take part in the flow of the application. The ViewResolvers are arranged in order of priority (0, 1, 2, ..). If ViewResolver (0) does not find the required "View Name" , the ViewResolver (1) will be used, ...

---

Interface ResourcePatternResolver

Can be used with any sort of location pattern (e.g. "/WEB-INF/*-context.xml"): Input patterns have to match the strategy implementation. This interface just specifies the conversion method rather than a specific pattern format.

This interface also suggests a new resource prefix "classpath*:" for all matching resources from the class path. Note that the resource location is expected to be a path without placeholders in this case (e.g. "/beans.xml"); JAR files or classes directories can contain multiple files of the same name.

---