Proxy Pattern and DelegatingFilterProxy in Spring Framework
In Spring Framework, there is a filter whose name is DelegatingFilterProxy which its responsibilty are to proxy (wrap) the lifecycle of the real Filter Servlet for some specific purposes.
In this article, i will introduce 2 main key points: Proxy Pattern and DelegatingFilterProxy.
To simplify and keep you on track with what i did, i have removed some unused methods as well as some lines of code, of course, it will not affect to our demo. So, if you want to know a full version of these class. Just open your IDE and explore it by yourself. Believe me, by diving into this framework, your knowledege pertained to design would be reinforced significantly.
I appreciate every comments which build this topic up. It would be my honor when this topic brings to you some valuable knowledge. And if you observe something interesting about Spring, just inbox or comment below, people are getting smarter by learning, sharing and communicating. It is always the best to learn from each other.
My Contact
- LinkedIn: Phan Hoang Minh Luan
- Facebook: Phan Hoang Minh Luan
- Email: phanhoangminhluan@gmail.com
Related to this article
Quick Recap
To follow until the end with this aricle, it is important to have some foundation knowledge related to Servlet Filter. It just a quick recap, you could skip this step if you have already learnt about Servlet Filter
Definition from docs.oracle.com
A filter is an object that performs filtering tasks on either the request to a resource (a servlet or static content), or on the response from a resource, or both.
As you can see, there are 3 methods which are:
init(FilterConfig): it will be invoked 1 time by web container, when request come to this filter
- destroy(): it will be invoked 1 time by web container, after a timeout period. When it get call, method doFilter() can not be call again.
- doFilter(ServletRequest, ServletResponse, FilterChain): it will be called each time a request come to Servlet. The FilterChain argument is to pass Request and Response to Servlet or to the next Filter.
Main Discussion
Proxy Design Pattern
The main purpose of proxy is to wrap your real object (in this case, realLogging) into a proxy object which lets you control access to the real object.
The clients do not need to care or even know about TextLogging, they only need to know about TextLoggingProxy which can help them to achieve there requirements.
For example, i will explain that UML chart in details
The real logging, which its mission is to print “write log to file”
As you can see method writeLogToFile() in TextLoggingProxy below. You can achieve the requirement which is to write log file and you can perform some pre-process or even post-process of this method.
So, what are the reasons for wrapping the real object by using proxy object ?
- Virtual Proxy: you have a resource-hungry object and you don’t want to instantiate that object each time it get call. You can deal with that problem by creating a proxy object that wrap that heavy object. That heavy object will be instantiated only one time when it’s needed for the first time.
- Protection Proxy: you need to authenticate and authorize the request before it accesses to the objects. It is not well-designed if you added some lines of code to change the class of the real object. By wrapping it using a proxy objects, it can adapt your requirement without change the structure of your old code.
Handling Filter in Spring
The picture belows indicates the hierrachy of DelegatingFilterProxy
In Java Servlet, class which implements Filter will receive request from client and activates some processes which i have shown in Quick Recap.
However, in Java Spring, the one (LoggingFilter) which implements Filter will not intercept request from client and it also acts as a Bean in IOC Container. That is the reason why we have to annotate @component on the top of LoggingFilter.
So which class will actually intercept request from client ? The answer is DelegatingFilterProxy which wrap the Filter (in this case, LoggingFilter).
To get the big picture of DelegatingFilterProxy, you can take a look at this UML schema to have the right overview towards this proxy filter.
At first, to use DelegatingFilterProxy, we have to declare it in AbstractAnnotationConfigDispatcherServletInitializer
Our concerntration is about method getServletFilters(). Let take a look of its implementations:
- setTargetBeanName(): because our LoggingFilter has been annotated @component so its bean name will be loggingFilter. This method is to find bean loggingFilter in IoC container
- setTargetFilterLifecycle(true): lifecyle’s method of Filter are init(), doFilter() and destroy(). If you set it false (default), init() and destroy() will not be invoked.
Moreover, to know how Filters are retrieved in container, you can take a look at this article for more details.
The picture below demonstrates how DelegatingFilterProxy is processed when the first request is come to container as well as how it destroy this filter. There are some line of codes which are removed for brevity and to help to concerntrate on the right purpose of this topic: understand how Filter are process under the hood in Spring Framework.
There are 3 ways you can use Filter in Spring, for more information, you can visit the article from Baeldung which inspires me a lots for writing this topic.
