Spring MVC — Drill Round 3

Two true: the 404 returns the custom message, and HttpClientErrorException covers 4xx

Take the three false claims one at a time, because each is a useful fact in its own right:

The design point behind all three: RestTemplate is deliberately thin. It performs one HTTP call and translates the outcome — it adds no retries, no fallbacks, no null handling. Anything resilience-shaped is somebody else's job.

try {
    return restTemplate.getForEntity(url, String.class).getBody();   // may be null
} catch (HttpClientErrorException e) {          // 4xx only
    if (e.getStatusCode() == HttpStatus.NOT_FOUND) return "Customer not found";
    throw e;
} catch (HttpServerErrorException e) {          // 5xx — needs its own catch
    throw e;
} catch (ResourceAccessException e) {           // never reached the server
    throw e;
}

HttpSession, Principal, Locale — the wrong options are near-miss names

This is a naming question dressed as a Spring question. Each wrong option is the plain English word for a real type:

"Language" is the giveaway. Java's type for language-and-region has been called Locale since JDK 1.1 — there has never been a Language type anywhere in the JDK or Spring. It's the same family as DifferentOf, BiggerThan and @NoRollback: an everyday word standing in for a technical one.

Note that Principal and Locale come from the JDK, not Spring. Spring resolves them for you — Locale via the LocaleResolver, Principal from the servlet container or Spring Security.

Converting between HTTP message bodies and Java objects

The distinction between the first two matters, because option 3 was close enough to be tempting: negotiation decides which media type; conversion does the actual work. The ContentNegotiationManager inspects the Accept header and answers "JSON"; the MappingJackson2HttpMessageConverter then turns your object into JSON bytes. Two steps, two components.

Where converters are used: @RequestBody (incoming — deserialise) and @ResponseBody / @RestController (outgoing — serialise). That's the message-conversion pipeline from round 1, and the converter is the thing doing the work in it.

ContentNegotiatingViewResolver

Read the stem's two clauses: "does not resolve views directly" and "delegates based on the client's requested representation". Only one resolver is a coordinator:

Its order is the tell: ContentNegotiatingViewResolver defaults to Ordered.HIGHEST_PRECEDENCE (well, Integer.MAX_VALUE - 10 in older configurations, but always first in the chain) — because it must run before the others in order to ask them all and choose between their answers. A resolver that delegates has to go first.

This connects to round 2's ViewResolver chain question: resolvers are tried in order, null means "pass". ContentNegotiatingViewResolver is the one that doesn't pass — it collects everyone's candidates and picks a winner.

Three things needed — and you keep both the JAR mode and @SpringBootApplication

@SpringBootApplication
public class DemoApplication extends SpringBootServletInitializer {

    @Override                                    // ← required for the container
    protected SpringApplicationBuilder configure(SpringApplicationBuilder app) {
        return app.sources(DemoApplication.class);
    }

    public static void main(String[] args) {     // ← still works standalone
        SpringApplication.run(DemoApplication.class, args);
    }
}

Both entry points coexist, and that's deliberate: developers run main() locally with embedded Tomcat, while CI produces a WAR for the shared container. The configure() override and the main() method are two doors into the same application.

One extra step the question didn't ask about but the exam sometimes does: mark the embedded server provided so it isn't packaged twice — spring-boot-starter-tomcat with <scope>provided</scope>.