SSH Consolidated web.xml filter and listener configuration
Delay Load Filter
Hibernate allows deferred loading of associated objects and properties, but must ensure that deferred loading is limited to the same Hibernate session scope. If the Service layer returns a domain object with deferred load enabled to the Web layer, when the Web layer accesses data that requires deferred loading, the Hibernate session of the loading domain object is closed, which results in an access exception that delays loading the data.
Spring specifically provides a
Opensessioninviewfilter filter, its primary function is to enable each request process to bind a Hibernate session, even if the original transaction has been completed, can also be delayed loading on the WEB layer.
The Opensessioninviewfilter filter binds the Hibernate session to the request thread, which is automatically detected by the Spring's transaction manager. So Opensessioninviewfilter is suitable for the service layer to use Hibernatetransactionmanager or Jtatransactionmanager for transaction management environment, can also be used in non-transactional read-only data operations.
To enable this filter, you must configure this in Web.xml:
...
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>
Org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>
...
For the above configuration, we assume that the. html suffix is used as the URL matching pattern for the web framework, and if you use a web framework such as Struts, you can change it to the corresponding "*.do" model.
Chinese garbled filter
When you submit data through the table one-way server, a classic problem is the Chinese garbled problem. Although all of our JSP files and page encoding formats are UTF-8, this problem still occurs. The solution is simple: we just need to configure a Spring code conversion filter in the Web.xml.
<web-app>
<!---listener Configuration-->
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>
Org.springframework.web.filter.characterencodingfilter①spring Edit Filter
</filter-class>
<init-param>② Encoding method
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<init-param>③ to force encoding conversions
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
Matching URL for <filter-mapping>② filter
<filter-name>encodingFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>
<!---servlet configuration-->
</web-app>
So all the URL requests with the. html suffix will be UTF-8 encoded format, and the problem of Chinese garbled form can be solved.
Request trace Log Filter
In addition to the two commonly used filters, there are two request log tracking filters that are likely to be used when the program is debugged, which records some of the important information requested in the log to facilitate debugging of the program. These two log filters work only if the log level is DEBUG:
Method description
Org.springframework.web.filter.ServletContextRequestLoggingFilter This filter logs the requested URI to the Common log (for example, a log file specified via log4j);
Org.springframework.web.filter.ServletContextRequestLoggingFilter This filter records the requested URI to the ServletContext log.
The following is a fragment of the request tracking log for log filter records:
(jspservlet.java:224)-Jspengine-->/htmltest.jsp
(jspservlet.java:225)-Servletpath:/htmltest.jsp
(jspservlet.java:226)-Pathinfo:null
(jspservlet.java:227)-realpath:d:/masterspring/chapter23/webapp/htmltest.jsp
(jspservlet.java:228)-RequestUri:/baobaotao/htmltest.jsp
...
By using this request to trace logs, the degree debugger can see in detail what requests are invoked, what parameters are requested, and whether the request returns correctly. Although these two request trace log filters are generally used during program debugging, it is not a big deal even if the program deployment does not remove them from the web.xml, because as long as the log level is set to above debug level, they do not output request trace log information.
Dump WEB application root listeners and log4j listeners
Spring provides several special-purpose Servlet listeners in the Org.springframework.web.util package, and uses them correctly to accomplish a number of specific requirements. For example, some Third-party tools support referencing system parameters via ${key} (that is, properties that can be obtained by System.getproperty ()), Webapprootlistener can add WEB application roots to system parameters. The corresponding property name can be specified by the Servlet context parameter named "Webapprootkey", which defaults to "Webapp.root". The following is the specific configuration of the listener:
Listing 6. Webapprootlistener Listener Configuration
...
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>baobaotao.root</param-value>①web applies the root directory to the system parameters by adding the property name
</context-param>
...
② is responsible for adding the WEB application root to the system parameters with the name of the property specified by the Webapprootkey context parameter
<listener>
<listener-class>
Org.springframework.web.util.WebAppRootListener
</listener-class>
</listener>
...
This allows you to obtain the root directory of the WEB application in the program by System.getproperty ("Baobaotao.root"). However, a more common use scenario is to refer to the root directory of the Web application through ${baobaotao.root} in a Third-party tool's configuration file. For example, the following log4j.properties configuration file sets the address of the log file via ${baobaotao.root}:
Log4j.rootlogger=info,r
Log4j.appender.r=org.apache.log4j.rollingfileappender
Log4j.appender.r.file=${baobaotao.root}/web-inf/logs/log4j.log① Specify the address of the log file
log4j.appender.r.maxfilesize=100kb
Log4j.appender.r.maxbackupindex=1
log4j.appender.r.layout.conversionpattern=%d%5p [%t] (%f:%l)-%m%n
Another listener dedicated to log4j is Log4jconfiglistener. In general, you must log4j.properties the log4j log profile to the file name and save it under the classpath. Log4jconfiglistener allows you to explicitly specify the address of the log4j configuration file through the Log4jconfiglocation Servlet context parameter, as follows:
① Specify the address of the log4j configuration file
<context-param>
<param-name>log4jConfigLocation</param-name>
<param-value>/WEB-INF/log4j.properties</param-value>
</context-param>
...
② Use this listener to initialize the log4j log engine
<listener>
<listener-class>
Org.springframework.web.util.Log4jConfigListener
</listener-class>
</listener>
...
Tips
Some Web application servers (such as TOMCAT) do not use separate system parameters for different Web applications, that is, all Web applications on the application server share the same system parameter object. At this point, you must specify a different property name for different Web applications by using the Webapprootkey context parameter: The first Web application uses Webapp1.root and the second Web application uses Webapp2.root, so that the latter does not have the problem of overwriting the former. In addition, both Webapprootlistener and Log4jconfiglistener can only be applied to Web application servers that will be extracted after the Web application deployment WAR file. Some Web application servers do not unpack the Web application's war file, and the entire Web application exists as a war package (such as Weblogic), and using both listeners will cause problems because the Web application root directory for the corresponding file system cannot be specified.
The Log4jconfiglistener listener includes Webapprootlistener features, that is, Log4jconfiglistener automatically completes the Web application root directory Webapprootkey The property name specified by the context parameter is added to the system parameters, so when you use Log4jconfiglistener, you do not have to use Webapprootlistener again.
Introspector Cache Cleanup Listener
Spring also provides a listener named Org.springframework.web.util.IntrospectorCleanupListener. It is primarily responsible for handling cache leaks caused by JavaBean introspector functions. The Introspectorcleanuplistener listener is responsible for clearing the JavaBean introspector cache when the Web application shuts down, registering the listener in Web.xml to release the Cla associated with the Web application shutdown Ssloader the cache and class references. If you use the classes in the JavaBean introspector analysis application, the Introspector cache retains references to these classes, and when applications are closed, these classes and Web application-related ClassLoader cannot be garbage collected. Unfortunately, the only way to clear Introspector is to refresh the entire cache, because it is impossible to determine exactly which references are part of this Web application, and which are reference objects belonging to other Web applications. So deleting the cached introspection will result in the deletion of all introspection of the entire JVM application. Note that spring-hosted beans do not need to use this listener, because the cache used by spring's introspection is cleared from the JavaBean introspector cache after parsing a class. and save the cache in application-specific ClassLoader, they generally do not cause memory resources to leak. But some class libraries and frameworks tend to create this problem. For example, the Introspector memory leaks of Struts and Quartz can cause the entire WEB application's ClassLoader to be garbage collected. After the Web application closes, you will also see all of the static class references to this application, and this error is certainly not caused by the class itself. The way to solve this problem is simple: You only need to configure the Introspectorcleanuplistener listener in Web.xml.
<listener>
<listener-class>
Org.springframework.web.util.IntrospectorCleanupListener
</listener-class>
</listener>
