Using Request Interceptors in Induction
- Using Request Interceptors in Induction
This tutorial discusses the use of request interceptors in Induction.
What is a Request Interceptor and what problem does its solve?
A request interceptor is a piece of code that gets activated for every single HTTP request received by your application. Interceptors are very useful when you need to perform some common processing for every HTTP request.
If not for request interceptor support we would have to put a call to the common processing code in every one of our controllers/views to achieve the same effect. Placing a call to our common code in every controller/view is not a convenient solution, when a new controller/view is added we need to remember to add the call to the common code. Now if we our call is to check something like security an ommission may have serious consequences. Interceptors offer a guaranteed way to call common code before (or after or at some other point as we shall shortly see) a controller/view executes. Next let's look at two examples of problems that may be solved elegantly using request interceptors.
Consider the problem of performing a check before the execution of certain types of controllers and/or views. For example, we may want certain controllers/views to only be callable if a user is logged in.
A request interceptor may also be used to manipulate cookie data. For example, certain application configurations require that the path of the session cookie created by the servlet container be changed, since the application is being proxied by a front-end web server (such as Apache's HTTP server) off a different path. In these configurations the web application runs in a servlet container (such as Tomcat) under a path such as /appname and is proxied by a front-end web server off the root of domain name such www.appname.com/. Now Tomcat creates the HTTP session cookie with the cookie path set to /appname, but since public browsers see the application hosted from / the cookie does not get sent back. We can solve this problem by using a simple request interceptor to write a cookie to the response with the same session data but with the path set to /.
What does an Request Interceptor look like?
An request interceptor is simply an ordinary Java class that is required to implement the interface com.acciente.induction.interceptor.RequestInterceptor. Induction looks for the method names preResolution, postResolution, preResponse and postResponse in our interceptor class. If it finds one or more of these methods they get called at different points in the request processing cycle.
For parameters declared in any of the methods Induction will attempt to inject a value based on the type. The parameter types for which Induction will inject values are documented here Interceptor METHODS : commonly used parameter types.
A request interceptor method is not required to return a value, however if a value is returned Induction processes returned value. Induction's rules for processing the return value are described below:
- If a request interceptor method returns the boolean value true then this is taken as signal that no further processing should be done on this request. The true can returned as either as a primitive type or as an object of type java.lang.Boolean.
- If a request interceptor method returns an object of type com.acciente.induction.controller.Redirect then this is also taken as signal that no further processing should be done on this request except processing the redirect request that the request interceptor returned.
- Any other type of return value that a request interceptor method may return is processed according to the view processing rules for controllers, described here Using Views in Induction.
Next lets look at when Induction calls each of the request interceptor methods.
- preResolution(...) this interceptor method is invoked PRIOR to attempting to resolve the target of the HTTP request using the controller and view resolvers.
- postResolution(...) this interceptor method is invoked AFTER attempting to resolve the target of the HTTP request using the controller and view resolvers.
- preResponse(...) this interceptor method called as follows:
- if the request resolved to a controller then this interceptor method is called AFTER the controller is executed but BEFORE the view or redirect object returned by the controller is processed.
- if the request resolved to a view then this interceptor method is called BEFORE the view is processed. Even though the interceptor is named preResponse, it is possible that the controller may have written to the response directly using a response object. But the name is consistent with the fact that this method called before any response that Induction sends to the client by executing a view (returned by a controller or view resolver) or a redirect object (returned by a controller).
- postResponse(...) this interceptor method is invoked AFTER processing a view or redirect object.