org.springframework.web.servlet Documentation Differences

This file contains all the changes in documentation in the package org.springframework.web.servlet as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

Extends {@code HandlerInterceptor} with a callback method invoked during asynchronous request handling.

When a handler starts asynchronous request handling, the DispatcherServlet exits without invoking {@code postHandle} and {@code afterCompletion}, as it normally does, since the results of request handling (e.g. ModelAndView) are will. not available in the currentbe produced concurrently in another thread and handling is not yet complete. In such scenarios, the .afterConcurrentHandlingStarted(HttpServletRequest, HttpServletResponse) method is invoked instead allowing implementations to perform tasks such as cleaningas cleaning up thread bound attributes.

When asynchronous handling completes, the request is dispatched to the container for further processing. At this stage the DispatcherServlet invokes {@code preHandle}, {@code postHandle} and {@code afterCompletion} as usual. @author Rossen Stoyanchev @since 3.2 @see org.springframework.web.context.request.async.WebAsyncManagerWebAsyncManager @see org.springframework.web.context.request.async.CallableProcessingInterceptor @see org.springframework.web.context.request.async.DeferredResultProcessingInterceptor

Called instead of {@code postHandle} and {@code afterCompletion}, when the when the a handler is being executed concurrently. Implementations may use thethe provided provided request and response but should avoid modifying them in waysways that would would conflict with the concurrent execution of the handler. AA typical use of of this method would be to clean thread local variables. @param request the current request @param response the current responseresponse @param handler handler (or HandlerMethod) that started async execution, for type and/or instance examination @throws Exception in case of errors

Workflow interface that allows for customized handler execution chains. Applications can register any number of existing or custom interceptors for certain groups of handlers, to add common preprocessing behavior without needing to modify each handler implementation.

A HandlerInterceptor gets called before the appropriate HandlerAdapter triggers the execution of the handler itself. This mechanism can be used for a large field of preprocessing aspects, e.g. for authorization checks, or common handler behavior like locale or theme changes. Its main purpose is to allow for factoring out repetitive handler code.

In an async processing scenario, the handler may be executed in a separate thread while the main thread exits without rendering or invoking the {@code postHandle} and {@code afterCompletion} callbacks. When concurrent handler execution completes, the request is dispatched back in order to proceed with rendering the model and all methods of this contract are invoked again. For further options and commentsdetails see {@code org.springframework.web.servlet.HandlerInterceptorAsyncHandlerInterceptor}

Typically an interceptor chain is defined per HandlerMapping bean, sharing its granularity. To be able to apply a certain interceptor chain to a group of handlers, one needs to map the desired handlers via one HandlerMapping bean. The interceptors themselves are defined as beans in the application context, referenced by the mapping bean definition via its "interceptors" property (in XML: a <list> of <ref>).

HandlerInterceptor is basically similar to a Servlet 2.3 Filter, but in contrast to the latter it just allows custom pre-processing with the option of prohibiting the execution of the handler itself, and custom post-processing. Filters are more powerful, for example they allow for exchanging the request and response objects that are handed down the chain. Note that a filter gets configured in web.xml, a HandlerInterceptor in the application context.

As a basic guideline, fine-grained handler-related preprocessing tasks are candidates for HandlerInterceptor implementations, especially factored-out common handler code and authorization checks. On the other hand, a Filter is well-suited for request content and view content handling, like multipart forms and GZIP compression. This typically shows when one needs to map the filter to certain content types (e.g. images), or to all requests. @author Juergen Hoeller @since 20.06.2003 @see HandlerExecutionChain#getInterceptors @see org.springframework.web.servlet.handler.HandlerInterceptorAdapter @see org.springframework.web.servlet.handler.AbstractHandlerMapping#setInterceptors @see org.springframework.web.servlet.handler.UserRoleAuthorizationInterceptor @see org.springframework.web.servlet.i18n.LocaleChangeInterceptor @see org.springframework.web.servlet.theme.ThemeChangeInterceptor @see javax.servlet.Filter

Callback after completion of request processing, that is, after rendering the view. Will be called on any outcome of handler execution, thus allows for proper resource cleanup.

Note: Will only be called if this interceptor's preHandle method has successfully completed and returned true!

As with the {@code postHandle} method, the method will be invoked on each interceptor in the chain in reverse order, so the first interceptor will be the last to be invoked. @param request current HTTP request @param response current HTTP response @param handler chosen handler to(or HandlerMethod) that started executeasync execution, for type and/or instance examination @param ex exception thrown on handler execution, if any @throws Exception in case of errors

Intercept the execution of a handler. Called after HandlerAdapter actually invoked the handler, but before the DispatcherServlet renders the view. Can expose additional model objects to the view via the given ModelAndView.

DispatcherServlet processes a handler in an execution chain, consisting of any number of interceptors, with the handler itself at the end. With this method, each interceptor can post-process an execution, getting applied in inverse order of the execution chain. @param request current HTTP request @param response current HTTP response @param handler chosen handler to(or HandlerMethod) executethat started async execution, for type and/or instance examination @param modelAndView the ModelAndView that the handler returned (can also be null) @throws Exception in case of errors

Name of the HttpServletRequest attribute that contains a Map with path variables. The map consists of String-based URI template variable names as keys and their correspondingcorresponding Object-based values -- extracted from segments of the URL and type converted.

Note: This attribute is not required to be supported by all View implementations.