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

Spring - Operations with jdbcTemplate

This class manages all the database communication and exception handling using a java.sql.Connection that is obtained from the provided DataSource. JdbcTemplate is a stateless and threadsafe class and you can safely instantiate a single instance to be used for each DAO.

Use of Callback Methods
JdbcTemplate is based on a template style of programming common to many other parts of Spring. Some method calls are handled entirely by the JdbcTemplate, while others require the calling class to provide callback methods that contain the implementation for parts of the JDBC workflow. This is another form of Inversion of Control. Your application code hands over the responsibility of managing the database access to the template class. The template class in turn calls back to your application code when it needs some detail processing filled in. These callback methods are allowed to throw a java.sql.SQLException, since the framework will be able to catch this exception and use its built-in excepti…