View Resolution Architecture and Configuration

Spring MVC isolates the presentation layer from the core framework through a modular view resolution system. Developers can switch rendering engines without altering business logic by defining the appropriate ViewResolver bean in the configuration file. This approach aligns with the Open/Closed Principle, ensuring low coupling and high extensibility across different template technologies.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context https://www.springframework.org/schema/context/spring-context.xsd">

    <context:component-scan base-package="com.example.web.controllers"/>

    <bean id="thymeleafViewHandler" class="org.thymeleaf.spring6.view.ThymeleafViewResolver">
        <property name="characterEncoding" value="UTF-8"/>
        <property name="order" value="1"/>
        <property name="templateEngine">
            <bean class="org.thymeleaf.spring6.SpringTemplateEngine">
                <property name="templateResolver">
                    <bean class="org.thymeleaf.spring6.templateresolver.SpringResourceTemplateResolver">
                        <property name="prefix" value="/views/pages/"/>
                        <property name="suffix" value=".html"/>
                        <property name="templateMode" value="HTML"/>
                        <property name="characterEncoding" value="UTF-8"/>
                    </bean>
                </property>
            </bean>
        </property>
    </bean>
</beans>

Modifying the bean definition seamlessly integrates alternative view technologies.

Supported View Implementations

The framework ships with several built-in and third-party view handlers:

• InternalResourceView: Handles internal resources, primarily designed for JSP.
• RedirectView: Manages HTTP redirection scenarios.
• ThymeleafView: Integrates with the Thymeleaf templating engine.
• FreeMarkerView / VelocityView: Supports respective third-party template syntaxes.
• PDFView / ExcelView: Generates binary document streams.

Core Pipeline Components

The view rendering mechanism relies on a coordinated set of classes:

• DispatcherServlet: Orchestrates the request lifecycle and delegates processing via doDispatch.
• ViewResolver: Translates a logical identifier into a concrete View instance. The primary contract is resolveViewName.
• View: Executes the rendering process, merging model attributes with template markup to produce an HTTP response. The core contract is render.
• ViewResolverRegistry: Registers resolver instances during context initialization, sorting them by priority.

To implement a custom rendering strategy, create a class implementing ViewResolver to handle name mapping, and another implementing View to process template transformation and response writing.

Execution Workflow

When a request enters the system:

1. The client sends an HTTP request to the server.
2. DispatcherServlet intercepts and identifies the target controller.
3. The controller executes business logic and returns a string identifier.
4. The dispatcher queries the registered ViewResolver chain, converting the string into a physical resource path and instantiating the appropriate View object.
5. The dispatcher invokes the View instance, which processes the template, attaches model data, and streams the final markup back to the client.

Logical to Physical Mapping

The final file path is constructed by combining the controller's return value with the resolver's prefix and suffix configurations.

package com.example.web.controllers;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class DashboardNavigation {

    @GetMapping("/")
    public String loadDashboard() {
        return "dashboard";
    }
}

If the active resolver uses /views/pages/ as a prefix and .html as a suffix, "dashboard" resolves to /views/pages/dashboard.html. Switching to a JSP-based resolver with /app/legacy/ and .jsp would map the same string to /app/legacy/dashboard.jsp.

Forwarding and Redirection Mechanisms

Forwarding executes entirely on the server, preserving the original request context and keeping the browser URL unchanged. Redirection sends a client-side instruction to fetch a new resource, updating the address bar and enabling cross-domain routing.

By default, returning a string from a controller triggers a forward. To explicitly route to another controller endpoint, prepend forward:. This bypasses standard view resolution and instantiates an InternalResourceView.

@Controller
public class WorkflowHandler {

    @GetMapping("/step1")
    public String initiateProcess() {
        return "forward:/step2";
    }

    @GetMapping("/step2")
    public String completeProcess() {
        return "result";
    }
}

For redirection, use the redirect: prefix. This creates a RedirectView object, instructing the client to issue a new GET request.

@GetMapping("/transfer")
public String externalTransfer() {
    return "redirect:/partner/api/callback";
}

Debugging these flows reveals that forward: constructs an InternalResourceView, while redirect: instantiates a RedirectView. Subsequent requests after a redirect proceed through the standard view resolution pipeline.

Simplified View Routing

The <mvc:view-controller> directive maps a URL directly to a logical view name without requiring a dedicated controller class. This is ideal for static landing pages or standard error screens.

<mvc:view-controller path="/welcome" view-name="home" />
<mvc:annotation-driven />

Enabling this mapping requires the <mvc:annotation-driven /> configuration. Omitting it will disable annotation-based controller processing, resulting in 404 errors for standard endpoints.

Static Resource Delivery

Configuring DispatcherServlet with url-pattern="/" intercepts all traffic, including CSS, JavaScript, and image files. To prevent 404 errors on asset requests, apply one of the following strategies.

Strategy A: Fallback to Container Defaults The <mvc:default-servlet-handler/> directive delegates unmatched requests to the servlet container's native static file handler. It must be paired with <mvc:annotation-driven />. When the dispatcher fails to locate a controller, the container's DefaultServlet serves the requested file directly from the web root.

<mvc:annotation-driven />
<mvc:default-servlet-handler />

Strategy B: Explicit Resource Mapping The <mvc:resources> tag provides precise control over asset routing. Define a URL pattern and a corresponding directory location.

<mvc:annotation-driven />
<mvc:resources mapping="/assets/**" location="/public/static/" />

Requests matching /assets/** bypass controller logic and are served from /public/static/. This approach also requires <mvc:annotation-driven /> to register the resource handler chain.