Servlet3.0 new features of web-fragment.xml modular configuration file

Servlet3.0 new feature introduction:

As a member of the Java EE 6 specification system, Servlet 3.0 was released with the Java EE 6 specification. This version provides several new features based on the previous version (Servlet 2.5) to simplify the development and deployment of Web applications. The introduction of several of these features has made developers very excited, and has also received praise from the Java community:

1. Asynchronous processing support: With this feature, the Servlet thread no longer needs to block all the time, and then the response can not be output until the business processing is completed, and finally the Servlet thread is ended. After receiving the request, the Servlet thread can delegate the time-consuming operation to another thread to complete, and return to the container without generating a response. In view of the time-consuming business processing, this will greatly reduce the occupation of server resources and increase the speed of concurrent processing.
2. New annotation support: This version adds several annotations to simplify the declaration of Servlet, Filter and Listener, which makes the web.xml deployment description file is no longer necessary from this version. Yes.
3. Pluggability support: Developers familiar with Struts2 will certainly remember the integration features of various common frameworks including Spring through plugins. The corresponding plug-ins are packaged into JAR packages and placed on the class path, and Struts2 can automatically load these plug-ins during runtime. Servlet 3.0 now provides similar features. Developers can easily extend the functionality of existing Web applications through plug-ins without modifying the original applications.

Note: About Servlet3.0 today demonstrate the new features focus on web-fragment.xml modular configuration file (the actual project experience) , on the other new features can refer to this article: Servlet3.0 Detailed new features  or Bo Friends of the article

 

1. What is the difference between web-fragment.xml and web.xml?

The common web.xml file template is:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1">
................
</web-app>

 

The web-fragment.xml file template is:

<?xml version="1.0" encoding="UTF-8"?>
<web-fragment id="WebFragment_ID" version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd">

............
    
 </web-fragment>

The first is that the root tag is not the same. The normal web.xml file tag is <web-app> </ web-app> This represents the main Java web project configuration file, and the web-fragment.xml file root tag is <web-fragment > </ web-fragment>, and web-fragment.xml and web.xml except for the XSD reference declared in the header, the main configuration is exactly the same as web.xml, Servlet 3.0 introduced the " The web-fragment.xml deployment description file of "Web Module Deployment Descriptor Fragment" must be stored in the META-INF directory of the JAR file. The deployment description file can contain everything that can be defined in web.xml. The JAR package is usually placed in the WEB-INF / lib directory. In addition, all the resources used by the module, including class files and configuration files, only need to be loaded on the path of the container's class loader chain, such as classes Directory etc. It can be said that this new feature is still very practical. You do n’t need to put all the bloated configurations in the web.xml file. You can configure all the initial configurations in the web-fragment.xml file, such as in a distributed project. Spring package scanning will have corresponding specifications in some companies. Even controllers and services require package names to comply with the specifications, so that we can extract a project and load the spring configuration file uniformly on the web. -fragment.xml to load these spring configuration files, so that in other developers' work, you don't need to configure the spring's almost repeated configuration every time, directly refer to the corresponding jar package to complete the configuration, which can improve efficiency .

E.g:

 

 ******************************************

 

 In this way, after other developers refer to the project, you can do "0 configuration spring" to use the convenience brought by spring.

 

2. The execution order of web.xml and web-fragment.xml?

* First of all: web.xml is definitely the first to be executed because web.xml is the entrance to the web project

* The execution order of multiple web-fragement.xml can be configured. Examples:

Using the <absolute-ordering> element in the deployment descriptor ( web.xml ) , you can set the absolute order as follows:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" 
id="WebApp_ID" version="3.0">
    <name>MyApp</name>
    <absolute-ordering>
        <name>MyFragment1</name>
        <name>MyFragment2</name>
    </absolute-ordering>
    ...

</web-app>

Relative ordering of web fragments:

Using the <ordering> element in web-fragment.xml , you can set the relative order. Three different web-fragment.xml files are given below, as follows:

web-fragment.xml：

<web-fragment>
    <name>MyFragment1</name>
    <ordering><after><name>MyFragment2</name></after></ordering>
    ...
</web-fragment>

web-fragment.xml：

<web-fragment>
    <name>MyFragment2</name>
    ...
</web-fragment>

web-fragment.xml：

<web-fragment>
    <name>MyFragment3</name>
    <ordering><before><others/></before></ordering>
    ..
</web-fragment>

The <before> indicates that the containing fragment must be booked before the fragment name to provide nested < name > tags. The <after> tag specifies that the clip must be sorted after the clip name provided under the nested <name> tag . The < before > < others /> </ before >  indicates that the containing fragment must be the first in the order after web.xml.

The sequence of the above webpage fragments is as follows:

1. MyFragment3
   
   
2. MyFragment2
   
   
3. MyFragment1

References from: Sorting Web Fragments

 

3. Actual demonstration effect?

* First create a test maven project, here is only web-fragment.xml file, the others are not just for demonstration:

Configure the context-param parameter in the web-fragment.xml file:

 Then install to local warehouse

 Note: This file must be stored in the META-INF directory of the JAR file and configured in maven:

      <build>
        <resources>
          <resource>
             <directory>src/main/resources</directory>
             <targetPath>META-INF/</targetPath>
          </resource>
       </resources>
    </build>

*****************

* Create a AA javaweb project, add a listener, or context parameters:

 

 

Start project printing results:

 

 It can be seen from the results that the parameters of the web-fragment.xml configuration in the test project take effect, and only the application of the jar package can complete the modular configuration of the web.xml file.