The first phase involves determination of the path of execution by a handler mapping. The path of execution consists of zero or more interceptors and exactly one handler.
A handler(Controller) is the component actually handling the request. it is used to prepare a model using incoming information from the servlet request.
Interceptors are also components involved in the path of execution, intercepting the request, because thy are giving a chance to execute a piece of logic before and right after the handler does its work. Interceptors are a Good Thing because they allow you to ad additional logic to the path of execution, without affecting the handler itself. Interceptors resemble Servlet Filters a bit; those are also capable of intercepting the request to modify it or execute other behavior. Servlet Filters are part of the Servlet 2.3 specification. They differ from Sspring HandlerInterceptors in that Filters are modeled on a more framwork-independent level and allow for interaction with the request and the response at a lower level. Spring handlerInterceptors are aware they're being executed in the context of the Spring Framework and allow for more framework-focused behavior.
After the path of execution has been determined, any interceptors found will be given a chance to intercept the incoming request. Each one of the interceptors can decide to stop the framework from further processing the request.
After a request has been preporcessed by the interceptors that were found(if any), Spring hands over control to the handler associated with the request.Such a handler should return a ModelAndView object. There are a couple of possible outcomes.
First of all, an exception might be thrown. In this case, Spring will inspect the WebapplicationContext for exception resolvers. Exception resolvers are components capable for inspecting an exception and determining an appropriate model-and-view relevant to the exception, as below,
<bean id="exceptionResolver"
class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
<property name="defaultErrorView">
<value>error</value>
</property>
<property name="exceptionMappings">
<props>
<prop key="java.sql.SQLException">errorDB</prop>
<prop key="java.lang.RuntimeException">errorRT</prop>
</props>
</property>
</bean>
Processing of the request should always result in a ModelAndView. If no ModelAndView is returned, Spring assumes that the handler itself has dealt with the request and no further action is taken(meaning Spring won't start rendering a view).
All interceptors available in the path of exectuion are allowed to post process the request, just before Spring starts rendering a response and also after rendering has finished.Finally, Spring informs you of the fact that request execution has finished. It does so using the event notification infrastructure of the ApplicationContext.
Summary: The whole processes:
Call to preHandle(HttpServletRequest, HttpServletResponse, Object) on any HandlerInterceptor available in the chain of execution. The Object in this case is the handler from the chain. This call allows to you execute any logic before the actual handler is allowed to do its job. Here you can check whether or not a user is allowed to issue this request, for example (this could be done using a UserRoleAuthorizationInterceptor explained a bit further on). Based on the return value of the call, Spring will decide to proceed with handling the request. When returning false, the dispatcher assumes the interceptor has handled the request itself (for example, when security constraints should prevent a user from issuing the request). In such a case Spring will immediately stop handling the request, which means the remaining interceptors, on which preHandle() hasn't been called, won't be consulted, just as the handler itself won't be consulted. Any interceptor, however, that did successfully return true before this moment will receive an afterCompletion() call.
Retrieve the handler from the HandlerExecutionChain and start looking for a HandlerAdapter. All available HandlerAdapters (registered in the WebApplicationContext or provided by default) will be inspected to see if one of them supports such a handler (usually determined, based on the class of the handler). In all except some complex and maybe rare situations there is no need to worry about the HandlerAdapter, its implementations, and the way they work. Spring's default behavior works just fine.
The next step is the actual execution of the handler. This will execute your actual business logic, or better; after some initial preparation such as data-binding, delegate the request to the middle tier. After the execution of the request has completed, you should prepare a ModelAndView, containing data that a JSP or, for example, a Velocity template needs to render an HTML page or a PDF document.
Next, all interceptors will be called again, using the postHandle(HttpServletRequest, HttpServletResponse, Object, ModelAndView) method. Here you can modify the ModelAndView (maybe add extra attributes to it or maybe even remove things). This is your last chance to execute logic before the view gets rendered.
Next, the view will be resolved and rendered. We will cover view resolving and rendering later in this chapter.
The last step involves calling afterCompletion(HttpServletRequest, HttpServletResponse, Object, Exception) on any interceptor available. The object is the handler that took care of the logic involved with this request. If an exception has occurred during the completion of the request, it will be passed in there as well.
A handler(Controller) is the component actually handling the request. it is used to prepare a model using incoming information from the servlet request.
Interceptors are also components involved in the path of execution, intercepting the request, because thy are giving a chance to execute a piece of logic before and right after the handler does its work. Interceptors are a Good Thing because they allow you to ad additional logic to the path of execution, without affecting the handler itself. Interceptors resemble Servlet Filters a bit; those are also capable of intercepting the request to modify it or execute other behavior. Servlet Filters are part of the Servlet 2.3 specification. They differ from Sspring HandlerInterceptors in that Filters are modeled on a more framwork-independent level and allow for interaction with the request and the response at a lower level. Spring handlerInterceptors are aware they're being executed in the context of the Spring Framework and allow for more framework-focused behavior.
After the path of execution has been determined, any interceptors found will be given a chance to intercept the incoming request. Each one of the interceptors can decide to stop the framework from further processing the request.
After a request has been preporcessed by the interceptors that were found(if any), Spring hands over control to the handler associated with the request.Such a handler should return a ModelAndView object. There are a couple of possible outcomes.
First of all, an exception might be thrown. In this case, Spring will inspect the WebapplicationContext for exception resolvers. Exception resolvers are components capable for inspecting an exception and determining an appropriate model-and-view relevant to the exception, as below,
<bean id="exceptionResolver"
class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
<property name="defaultErrorView">
<value>error</value>
</property>
<property name="exceptionMappings">
<props>
<prop key="java.sql.SQLException">errorDB</prop>
<prop key="java.lang.RuntimeException">errorRT</prop>
</props>
</property>
</bean>
Processing of the request should always result in a ModelAndView. If no ModelAndView is returned, Spring assumes that the handler itself has dealt with the request and no further action is taken(meaning Spring won't start rendering a view).
All interceptors available in the path of exectuion are allowed to post process the request, just before Spring starts rendering a response and also after rendering has finished.Finally, Spring informs you of the fact that request execution has finished. It does so using the event notification infrastructure of the ApplicationContext.
Summary: The whole processes:
Call to preHandle(HttpServletRequest, HttpServletResponse, Object) on any HandlerInterceptor available in the chain of execution. The Object in this case is the handler from the chain. This call allows to you execute any logic before the actual handler is allowed to do its job. Here you can check whether or not a user is allowed to issue this request, for example (this could be done using a UserRoleAuthorizationInterceptor explained a bit further on). Based on the return value of the call, Spring will decide to proceed with handling the request. When returning false, the dispatcher assumes the interceptor has handled the request itself (for example, when security constraints should prevent a user from issuing the request). In such a case Spring will immediately stop handling the request, which means the remaining interceptors, on which preHandle() hasn't been called, won't be consulted, just as the handler itself won't be consulted. Any interceptor, however, that did successfully return true before this moment will receive an afterCompletion() call.
Retrieve the handler from the HandlerExecutionChain and start looking for a HandlerAdapter. All available HandlerAdapters (registered in the WebApplicationContext or provided by default) will be inspected to see if one of them supports such a handler (usually determined, based on the class of the handler). In all except some complex and maybe rare situations there is no need to worry about the HandlerAdapter, its implementations, and the way they work. Spring's default behavior works just fine.
The next step is the actual execution of the handler. This will execute your actual business logic, or better; after some initial preparation such as data-binding, delegate the request to the middle tier. After the execution of the request has completed, you should prepare a ModelAndView, containing data that a JSP or, for example, a Velocity template needs to render an HTML page or a PDF document.
Next, all interceptors will be called again, using the postHandle(HttpServletRequest, HttpServletResponse, Object, ModelAndView) method. Here you can modify the ModelAndView (maybe add extra attributes to it or maybe even remove things). This is your last chance to execute logic before the view gets rendered.
Next, the view will be resolved and rendered. We will cover view resolving and rendering later in this chapter.
The last step involves calling afterCompletion(HttpServletRequest, HttpServletResponse, Object, Exception) on any interceptor available. The object is the handler that took care of the logic involved with this request. If an exception has occurred during the completion of the request, it will be passed in there as well.
Comments
Post a Comment