Exploration of Spring 3.1 without Web.xml-based servlet3.0 application of code configuration __web

(The article is written with the December 21, 11, originally published on the Iteye, guided over) some days ago, the spring framework has a new version of 3.1 release. Should be on December 13, 11, because springframework resource downloads need to enter some personal information, the system should have a record of which users are interested in which resources, so my mailbox has 3.1 release information, along the mailbox point to the page, There is an overview of the new version of Juergen. Glancing at it, the servlet 3.0 webapplicationinitializer mechanism was interested, so I made a special look at it today.

Through: When you create a new servlet3.0 WebApp in Eclipse, you will have a Web.xml file options, it is obvious that the servlet3.0 has no mechanism to create web.xml, naturally think of the annotation-style configuration, so it is easy to use code assistance in Eclipse editor to find the @webservlet,@webfilter , @WebInitParam, @WebListener and other annotations. It is under Javax.servlet.annotation, and is generally stored in the server's lib. Like my vfabric TC server, in the Serverlt-api.jar under Lib. Annotations do not need to look at the source code, it is in eclipse to see its name and method will be used. That is to say, the servlet, Listener, and the filter code directly annotate, the server can find them, so that will save the web.xml. The problem at the time was that most of the web.xml configurations of the Web programs you see are those of the third-party framework. In other words, if you want to use the Servlet3 annotation configuration, you need to download the framework of the source code added annotation and then compile. This is nothing but a very cumbersome thing, many people development, management of this recompile framework, but also a headache, this inconvenience let me not to taste.

        Maybe someone's wondering, We have been familiar with the Web.xml configuration, why to get a new configuration method, but also to go with it, and XML documents easy to understand and versatility, convenient for the deployment of the program users modify parameters. Do not try not to know, change the reasons for the annotation you will naturally understand after you try.              personal opinion: First, save time and improve efficiency. Think of the Hibernate hbm files all merged into the entity class, we no longer need to look at. java files, and sometimes look at HBM files. Switching files in editor is a waste of time, sometimes the brain is interrupted by something else, and another file needs to be reset to make sure that every mapping is correct; to mapping correctly, you need to switch from one file to another to copy/paste, Greatly reduce the development efficiency. The Spring framework's component-scan also has the same effect. Those @component, @Controller, @Service, @Repository really great satisfaction. Then there is the convenience of the user things, we can install the program to do the page. Having the deployment user look at an XML file is inherently a bad UE.
        back to current: This back to Spring 3.1 's code based Web program initialization, Let me think about it. Spring adds those @webxxxxx annotations to an existing class and looks at it eagerly. The result is supposed to be wrong.
        Well, first of all, briefly literacy its usage:
        In a word: Implement Interface Org.springframework.web.WebApplicationInitializer, overwrite public void Onstartup (ServletContext container) throw Servletexception method.
        as follows:

The public class Mywebappinitializer implements Webapplicationinitializer {@Override the public 
            void Onstartup ( ServletContext container) { 
            Xmlwebapplicationcontext appcontext = new Xmlwebapplicationcontext (); 
            Appcontext.setconfiglocation ("/web-inf/spring/dispatcher-config.xml"); 
                /*add self-defined servlet*/ 
            servletregistration.dynamic dispatcher = 
                Container.addservlet ("Dispatcher", New Dispatcherservlet (Appcontext)); 
            Dispatcher.setloadonstartup (1); 
            Dispatcher.addmapping ("/"); 
    } 
 
    

This simply replaces the Web.xml file and attaches a simple example of adding a servlet configuration. ServletContext can also be addfilter, AddListener, and the parameters of these two methods are an instance of a filter,listener.
Compare the same code in the original web.xml:

<servlet> 
   <servlet-name>dispatcher</servlet-name> 
   <servlet-class> 
     Org.springframework.web.servlet.DispatcherServlet 
   </servlet-class> 
   <init-param> 
     < Param-name>contextconfiglocation</param-name> 
     <param-value>/web-inf/spring/ dispatcher-config.xml</param-value> 
   </init-param> 
   <load-on-startup>1</ load-on-startup> 
 </servlet> 
 
 <servlet-mapping> 
   <servlet-name>dispatcher</ Servlet-name> 
   <url-pattern>/</url-pattern> 
 

All in all, the configuration in Web.xml can be in this onstartup method. You do not have to write any configuration, the server with servlet3.0 support will automatically find this Mywebappinitializer Onstartup method to start the application. Spring will also annotate the Applicationcontext.xml spring configuration, which means that the dispatcher-config.xml of the preceding code snippet can be changed to:

Annotationconfigwebapplicationcontext Rootcontext = 
        new Annotationconfigwebapplicationcontext (); 
        Rootcontext.register (Appconfig.class); 
        

AppConfig is a custom class, with @configuration annotations.

But here's the thing: This setup doesn't work, it's just replacing the Web.xml file with a custom class, and we need to make sure the written listener/servlet/filter is mapping correctly into the Onstartup method.
In fact, the question that fills my mind is how the server actually found the Onstartup method.  There are no annotations. Spring is playing magic. It's very simple to do a deeper look. Sell a piece of paper and put it in the next article.
After the work of the same thing is also a good solution: do not intentionally write Webapplicationinitialize implementation class, directly in each listener/filter/servlet you write to implement the interface and overwrite the Onstartup method, In each Onstartup method, only the container is added to itself.
This is the way I think, not try. Readers can try, I'm sure it's OK. Because I found this magic of spring, they used 30 lines of valid code to do a loop. And this short 30 lines show that this magic is all we can do in 10 minutes, in fact, the key is servlet3.0 strong. We didn't read the document carefully.
For practicality, this article is enough to solve.  The code copies the example of Webapplicationinitializer from Spring api:http://static.springsource.org/spring/docs/3.1.x/javadoc-api/. In addition, if you expect web.xml to coexist with a code-based configuration, you need to configure the Web.xml version to more than 3.0, and the following web.xml will be ignore out.
Attached: Xmlwebapplicationcontext and Annotationconfigwebapplicationcontext in package Org.springframework.web.support
Contextloaderlistener in the Org.springframework.web.
Other classes that do not mention the package name are in the Javax.servlet
Interested friends can read the next article << the Web.xml-based code-configurable servlet3.0 application of Spring 3.1 > >