The JAVA WEB filter (filter) injects beans into the container Spring

If you use the @Autoware get the bean directly, the bean is null because the method of configuring the filter cannot use the Spring bean in the filter because the filter is loaded first, that is, spring loads the filter The specified class to Container so that the Spring bean injected into the Filter is null.

Workaround:　　

1. Manually configure the Bean directly in the init () initialization method.

(1) Declaration of Commencement

1 NULL ; 2 null;

(2) Initialization method

1 @Override2      Public voidInit (Filterconfig filterconfig)throwsservletexception {3         //Configuring Beans Manually4ServletContext ServletContext =Filterconfig.getservletcontext ();5ApplicationContext =Webapplicationcontextutils.getwebapplicationcontext (ServletContext);6Menuservice = (menuservice) applicationcontext.getbean ("Menuservice");7}

(3) Use of the DoFilter () method

1 Menuservice.getownmenubyuserid (userid.tostring (), logintype.tostring ());

2. Proxy--delegatingfilterproxy class.

To configure a filter:

1 <Filter>  2     <Filter-name>Permission</Filter-name>  3     <Filter-class>Org.springframework.web.filter.DelegatingFilterProxy</Filter-class>  4 </Filter>  

In the Spring configuration file, configure:

1 <  ID= "Permission"  class= "Com.my.myfilter">  

The Delegatingfilterproxy class follows the Filter-name-bean principle of finding the same value in the spring configuration file as the ID of Filter-name, based on the value Filter-name in Web. XML, and then places the accepted Information to the corresponding class processing. If you want to customize the filter processing bean, you can add the following paragraph to the filter configuration:

 1  <  init-param   >  2   >  targetbeanname</  param-name  >  3  <  param-value  >  spring-bean-name</  Param-value  >  4  </ init-param  >  

This phrase specifies that the filter uses Spring-bean-name to process the request. At this point you will find that Filter.init () and filter.destory () cannot use spring beans because the lifecycle of the default Filter is managed by a server such as Tomcat, in the configuration:

 1  <  init-param   >  2   >  targetfilterlifecycle param-name  >  3  <  param-value  >  true</ param-value  Span style= "color: #0000ff;" >>  4  </ init-param  >  

This is where spring manages the life cycle of the filter so that the spring beans can be used in init () and Destory ().

There is another important thing, and sometimes you will find that when you request the filter processing URL, the program will error--no webapplicationcontext found:no contextloaderlistener registered?

The reason for this is that the filter is better than the servlet first loaded into the container, if we just configured the Org.springframework.web.servlet.DispatcherServlet in the Contextconfiglocation, if you specify a spring configuration file location, the program will not be able to access the spring bean, and the workaround is simple, on the Web. XML configuration:

1 <Context-param>  2     <Param-name>Contextconfiglocation</Param-name>  3     <Param-value>Classpath:/conf/web-context.xml</Param-value>  4 </Context-param>  5 <Listener>   6         <Listener-class>   7 Org.springframework.web.context.ContextLoaderListener8         </Listener-class>   9     </Listener>  

This allows the spring bean to be loaded into the container the first time, so there will be no webapplicationcontext found:no Contextloaderlistener registered? This is a mistake.

The first method of the above can be fully implemented, the second method is not tested, the second method source address:

http://blog.csdn.net/godha/article/details/13025099

The JAVA WEB filter (filter) injects beans into the container Spring