Eine Einführung in das Spring DispatcherServlet

1. Einleitung

Einfach ausgedrückt, im Entwurfsmuster des Front Controllers ist ein einzelner Controller dafür verantwortlich, eingehende HttpRequests an alle anderen Controller und Handler einer Anwendung weiterzuleiten .

Das DispatcherServlet von Spring implementiert dieses Muster und ist daher dafür verantwortlich, die HttpRequests korrekt an die rechten Handler zu koordinieren .

In diesem Artikel untersuchen wir den Workflow für die Anforderungsverarbeitung von Spring DispatcherServlet und wie mehrere der an diesem Workflow beteiligten Schnittstellen implementiert werden.

2. DispatcherServlet- Anforderungsverarbeitung

Im Wesentlichen verarbeitet ein DispatcherServlet eine eingehende HttpRequest , delegiert die Anforderung und verarbeitet diese Anforderung gemäß den konfigurierten HandlerAdapter- Schnittstellen , die in der Spring-Anwendung implementiert wurden, zusammen mit den zugehörigen Anmerkungen, in denen Handler, Controller-Endpunkte und Antwortobjekte angegeben sind.

Lassen Sie uns genauer erläutern, wie ein DispatcherServlet eine Komponente verarbeitet:

  • Der einem DispatcherServlet unter dem Schlüssel DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE zugeordnete WebApplicationContext wird gesucht und allen Elementen des Prozesses zur Verfügung gestellt
  • Das DispatcherServlet findet alle Implementierungen der HandlerAdapter- Schnittstelle, die mit getHandler () für Ihren Dispatcher konfiguriert wurden. Jede gefundene und konfigurierte Implementierung verarbeitet die Anforderung über handle () im weiteren Verlauf des Prozesses
  • Der LocaleResolver ist optional an die Anforderung gebunden, damit Elemente im Prozess das Gebietsschema auflösen können
  • Der ThemeResolver ist optional an die Anforderung gebunden, Elemente wie Ansichten bestimmen zu lassen, welches Thema verwendet werden soll
  • Wenn ein MultipartResolver angegeben ist, wird die Anforderung auf MultipartFile s überprüft. Alle gefundenen Daten werden zur weiteren Verarbeitung in eine MultipartHttpServletRequest eingeschlossen
  • Im WebApplicationContext deklarierte HandlerExceptionResolver- Implementierungen übernehmen Ausnahmen, die während der Verarbeitung der Anforderung ausgelöst werden

Weitere Informationen zum Registrieren und Einrichten eines DispatcherServlets finden Sie hier.

3. HandlerAdapter- Schnittstellen

Die HandlerAdapter- Schnittstelle erleichtert die Verwendung von Controllern, Servlets, HttpRequests und HTTP-Pfaden über mehrere spezifische Schnittstellen. Die HandlerAdapter- Schnittstelle spielt daher in den vielen Phasen des DispatcherServlet- Workflows für die Anforderungsverarbeitung eine wesentliche Rolle .

Zunächst wird jede HandlerAdapter- Implementierung von der getHandler () -Methode Ihres Dispatchers in die HandlerExecutionChain eingefügt . Anschließend behandelt jede dieser Implementierungen () das HttpServletRequest- Objekt, während die Ausführungskette fortschreitet.

In den folgenden Abschnitten werden einige der wichtigsten und am häufigsten verwendeten HandlerAdapter näher erläutert.

3.1. Zuordnungen

Um Zuordnungen zu verstehen, müssen wir uns zunächst ansehen, wie Controller mit Anmerkungen versehen werden, da Controller für die HandlerMapping- Schnittstelle so wichtig sind .

Der SimpleControllerHandlerAdapter ermöglicht die explizite Implementierung eines Controllers ohne eine @ Controller- Annotation.

Der RequestMappingHandlerAdapter unterstützt Methoden, die mit der Annotation @RequestMapping versehen sind .

Wir werden uns hier auf die Annotation @Controller konzentrieren , aber eine hilfreiche Ressource mit mehreren Beispielen, die den SimpleControllerHandlerAdapter verwenden, ist ebenfalls verfügbar.

Die Annotation @RequestMapping legt den spezifischen Endpunkt fest, an dem ein Handler in dem ihm zugeordneten WebApplicationContext verfügbar sein wird .

Sehen wir uns ein Beispiel eines Controllers an , der den Endpunkt '/ user / example' verfügbar macht und verarbeitet :

@Controller @RequestMapping("/user") @ResponseBody public class UserController { @GetMapping("/example") public User fetchUserExample() { // ... } }

Die in der Annotation @RequestMapping angegebenen Pfade werden intern über die HandlerMapping- Schnittstelle verwaltet.

Die URL-Struktur ist natürlich relativ zum DispatcherServlet selbst - und wird durch die Servlet-Zuordnung bestimmt.

Wenn das DispatcherServlet also '/' zugeordnet ist, werden alle Zuordnungen von dieser Zuordnung abgedeckt.

Wenn die Servlet-Zuordnung jedoch stattdessen ' / dispatcher ' lautet, sind alle @ RequestMapping- Anmerkungen relativ zu dieser Stamm-URL.

Denken Sie daran, dass '/' für Servlet-Zuordnungen nicht mit '/ *' identisch ist ! '/' ist die Standardzuordnung und stellt alle URLs dem Verantwortungsbereich des Dispatchers zur Verfügung.

‘/*' is confusing to a lot of newer Spring developers. It does not specify that all paths with the same URL context are under the dispatcher's area of responsibility. Instead, it overrides and ignores the other dispatcher mappings. So, ‘/example' will come up as a 404!

For that reason, ‘/*' shouldn't be used except in very limited circumstances (like configuring a filter).

3.2. HTTP Request Handling

The core responsibility of a DispatcherServlet is to dispatch incoming HttpRequests to the correct handlers specified with the @Controller or @RestController annotations.

As a side note, the main difference between @Controller and @RestController is how the response is generated – the @RestController also defines @ResponseBody by default.

A writeup where we go into much greater depth regarding Spring's controllers can be found here.

3.3. The ViewResolver Interface

A ViewResolver is attached to a DispatcherServlet as a configuration setting on an ApplicationContext object.

A ViewResolver determines both what kind of views are served by the dispatcher and from where they are served.

Here's an example configuration which we'll place into our AppConfig for rendering JSP pages:

@Configuration @EnableWebMvc @ComponentScan("com.baeldung.springdispatcherservlet") public class AppConfig implements WebMvcConfigurer { @Bean public UrlBasedViewResolver viewResolver() { UrlBasedViewResolver resolver = new UrlBasedViewResolver(); resolver.setPrefix("/WEB-INF/view/"); resolver.setSuffix(".jsp"); resolver.setViewClass(JstlView.class); return resolver; } }

Very straight-forward! There are three main parts to this:

  1. setting the prefix, which sets the default URL path to find the set views within
  2. the default view type which is set via the suffix
  3. setting a view class on the resolver which allows technologies like JSTL or Tiles to be associated with the rendered views

One common question involves how precisely a dispatcher's ViewResolverand the overall project directory structure are related. Let's take a look at the basics.

Here's an example path configuration for an InternalViewResolver using Spring's XML configuration:

For the sake of our example, we'll assume that our application is being hosted on:

//localhost:8080/

This is the default address and port for a locally hosted Apache Tomcat server.

Assuming that our application is called dispatcherexample-1.0.0, our JSP views will be accessible from:

//localhost:8080/dispatcherexample-1.0.0/jsp/

The path for these views within an ordinary Spring project with Maven is this:

src -| main -| java resources webapp -| jsp WEB-INF

The default location for views is within WEB-INF. The path specified for our InternalViewResolver in the snippet above determines the subdirectory of ‘src/main/webapp' in which your views will be available.

3.4. The LocaleResolver Interface

The primary way to customize session, request, or cookie information for our dispatcher is through the LocaleResolver interface.

CookieLocaleResolver is an implementation allowing the configuration of stateless application properties using cookies. Let's add it to AppConfig.

@Bean public CookieLocaleResolver cookieLocaleResolverExample() { CookieLocaleResolver localeResolver = new CookieLocaleResolver(); localeResolver.setDefaultLocale(Locale.ENGLISH); localeResolver.setCookieName("locale-cookie-resolver-example"); localeResolver.setCookieMaxAge(3600); return localeResolver; } @Bean public LocaleResolver sessionLocaleResolver() { SessionLocaleResolver localeResolver = new SessionLocaleResolver(); localeResolver.setDefaultLocale(Locale.US); localResolver.setDefaultTimeZone(TimeZone.getTimeZone("UTC")); return localeResolver; } 

SessionLocaleResolver allows for session-specific configuration in a stateful application.

The setDefaultLocale() method represents a geographical, political, or cultural region, whereas setDefaultTimeZone( ) determines the relevant TimeZone object for the application Bean in question.

Both methods are available on each of the above implementations of LocaleResolver.

3.5. The ThemeResolver Interface

Spring provides stylistic theming for our views.

Let's take a look at how to configure our dispatcher to handle themes.

First, let's set up all the configuration necessary to find and use our static theme files. We need to set a static resource location for our ThemeSource to configure the actual Themes themselves (Theme objects contain all of the configuration information stipulated in those files). Add this to AppConfig:

@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/resources/**") .addResourceLocations("/", "/resources/") .setCachePeriod(3600) .resourceChain(true) .addResolver(new PathResourceResolver()); } @Bean public ResourceBundleThemeSource themeSource() { ResourceBundleThemeSource themeSource = new ResourceBundleThemeSource(); themeSource.setDefaultEncoding("UTF-8"); themeSource.setBasenamePrefix("themes."); return themeSource; } 

Requests managed by the DispatcherServlet can modify the theme through a specified parameter passed into setParamName() available on the ThemeChangeInterceptor object. Add to AppConfig:

@Bean public CookieThemeResolver themeResolver() { CookieThemeResolver resolver = new CookieThemeResolver(); resolver.setDefaultThemeName("example"); resolver.setCookieName("example-theme-cookie"); return resolver; } @Bean public ThemeChangeInterceptor themeChangeInterceptor() { ThemeChangeInterceptor interceptor = new ThemeChangeInterceptor(); interceptor.setParamName("theme"); return interceptor; } @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(themeChangeInterceptor()); } 

The following JSP tag is added to our view to make the correct styling appear:


     

The following URL request renders the example theme using the ‘theme' parameter passed into our configured ThemeChangeIntercepter:

//localhost:8080/dispatcherexample-1.0.0/?theme=example

3.6. The MultipartResolver Interface

A MultipartResolver implementation inspects a request for multiparts and wraps them in a MultipartHttpServletRequest for further processing by other elements in the process if at least one multipart is found. Add to AppConfig:

@Bean public CommonsMultipartResolver multipartResolver() throws IOException { CommonsMultipartResolver resolver = new CommonsMultipartResolver(); resolver.setMaxUploadSize(10000000); return resolver; } 

Now that we've configured our MultipartResolver bean, let's set up a controller to process MultipartFile requests:

@Controller public class MultipartController { @Autowired ServletContext context; @PostMapping("/upload") public ModelAndView FileuploadController( @RequestParam("file") MultipartFile file) throws IOException { ModelAndView modelAndView = new ModelAndView("index"); InputStream in = file.getInputStream(); String path = new File(".").getAbsolutePath(); FileOutputStream f = new FileOutputStream( path.substring(0, path.length()-1) + "/uploads/" + file.getOriginalFilename()); int ch; while ((ch = in.read()) != -1) { f.write(ch); } f.flush(); f.close(); in.close(); modelAndView.getModel() .put("message", "File uploaded successfully!"); return modelAndView; } }

We can use a normal form to submit a file to the specified endpoint. Uploaded files will be available in ‘CATALINA_HOME/bin/uploads'.

3.7. The HandlerExceptionResolver Interface

Spring's HandlerExceptionResolver provides uniform error handling for an entire web application, a single controller, or a set of controllers.

To provide application-wide custom exception handling, create a class annotated with @ControllerAdvice:

@ControllerAdvice public class ExampleGlobalExceptionHandler { @ExceptionHandler @ResponseBody public String handleExampleException(Exception e) { // ... } }

Any methods within that class annotated with @ExceptionHandler will be available on every controller within dispatcher's area of responsibility.

Implementations of the HandlerExceptionResolver interface in the DispatcherServlet's ApplicationContext are available to intercept a specific controller under that dispatcher's area of responsibility whenever @ExceptionHandler is used as an annotation, and the correct class is passed in as a parameter:

@Controller public class FooController{ @ExceptionHandler({ CustomException1.class, CustomException2.class }) public void handleException() { // ... } // ... }

The handleException() method will now serve as an exception handler for FooController in our example above if either exception CustomException1 or CustomException2 occurs.

Here's an article that goes more in-depth about exception handling in a Spring web application.

4. Conclusion

In this tutorial, we've reviewed Spring's DispatcherServlet and several ways to configure it.

As always, the source code used in this tutorial is available over on Github.