Skip to main content

Spring - Workflow Involved with handling Requests

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"
    <property name="defaultErrorView">

    <property name="exceptionMappings">
           <prop key="java.sql.SQLException">errorDB</prop>
           <prop key="java.lang.RuntimeException">errorRT</prop>

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.


Popular posts from this blog

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold highlighted in example below) which resolve the problems.   example:
<band height="20" splitType="Stretch"> <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/> …

JasperReports - Configuration Reference

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know.

Symptom: 1.The JVM became Out of memory when creating big consumption report 2.Those JRTemplateElement-instances is still there occupied even if I logged out the system
Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.The clearobjects() method in ReportThread class has not been triggered when logging out
Action I tried:      About the Virtualizer: 1.Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory     About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object                Item 4,5 – result : it helps a lot to reduce the number of  JRTemplateE…