Spring MVC — Drill Round 2

HandlerMapping finds; HandlerAdapter invokes

Read the verb, not the noun. Both false options name a real component and pair it with the other one's verb. Mapping ⇒ HandlerMapping. Adapting/invoking ⇒ HandlerAdapter. The names literally say what they do.

Why two components rather than one: HandlerAdapter exists so the DispatcherServlet can invoke different kinds of handler uniformly — an @RequestMapping method, an old Controller interface implementation, an HttpRequestHandler. Finding and invoking are genuinely separate concerns.

Four of the five — ModelAndView is the odd one out because it's a return type

Everything Spring can inject goes through a HandlerMethodArgumentResolver. The list is long and generous — when a question asks "which may be arguments", the answer is usually "most of them":

@PostMapping("/orders/{id}")
public String handle(@PathVariable Long id,          // URI template
                     @RequestParam String mode,       // query string
                     @RequestBody OrderDto dto,       // body
                     @RequestHeader("X-Trace") String trace,
                     Principal principal,             // authenticated user
                     HttpSession session,             // session
                     HttpServletRequest request,      // raw request
                     Locale locale,                   // request locale
                     Model model) { … }               // model to populate

ModelAndView is the exception, and it's a clean rule: it bundles the model and the chosen view — a decision the handler makes, so it can only be produced, never supplied. Spring has nothing to put in it before your method runs.

All four — Errors, Model, ServletRequest, ServletResponse

The one worth learning properly is Errors/BindingResult, because it has a positional rule the exam likes:

@PostMapping("/users")
public String create(@Valid @ModelAttribute UserForm form,
                     BindingResult errors,        // ← MUST come immediately after
                     Model model) {
    if (errors.hasErrors()) return "form";
    …
}

Errors/BindingResult must be declared directly after the validated argument. Put anything between them and Spring can't associate the two — validation failures then throw MethodArgumentNotValidException (a 400) instead of populating the object you're holding. That's not a style rule; it's how the resolver pairs them.

ServletRequest/ServletResponse being valid is the mirror of the trap you keep meeting: valid as parameters, never as return types.

Four of five true — the false one is "getForEntity accepts an HttpEntity"

Why that call silently does the wrong thing — this is the genuinely interesting bit:

restTemplate.getForEntity(url, String.class, requestEntity);
//                                            ^^^^^^^^^^^^^
// getForEntity(String url, Class<T> type, Object... uriVariables)
// the varargs are URI TEMPLATE VARIABLES — the entity is treated as a
// value for {0} in the URL, and the headers are never sent.

It compiles, it runs, and the Authorization header simply isn't there. That's what makes it a good exam question and a nasty real-world bug.

postForObject hides the status · put and delete return void

The naming convention makes the whole API predictable:

Read the suffix and you know the answer: Object = just the body, Entity = the whole response. So "with postForObject it is impossible to check the status code" is true by construction — there's nowhere for it to appear.

Note also that RestTemplate throws on 4xx/5xx by default (HttpClientErrorException / HttpServerErrorException), so "checking the status" mostly means distinguishing among the 2xx codes.

All four — Tiles, Thymeleaf, XSLT and JSP

The instinct to correct: "supported by Spring" is much broader than "the Boot default". Thymeleaf is the default; JSP, XSLT and Tiles are older but genuinely supported. Only reject a view technology if it isn't one — which is how JSON slipped past you on a paper question.

Byte arrays, JAXB and JSON — not SOAP

Why SOAP is excluded is a real architectural point: message converters map a body to an object. SOAP isn't a body format — it's a full protocol with an envelope, headers, a WSDL contract and its own addressing. It can't be handled by a body converter, which is why it lives in a separate project, Spring-WS.

Converters are tried in order and the first supporting the negotiated media type wins — the same chain-of-responsibility shape as the ViewResolver chain.