Spring Technology Insider--deep analysis of spring architecture and design principles (i) IOC implementation principles

The foundation of the IOC
Here we start with the IOC/AOP, which is the core part of the spring platform implementation, although we started mostly at this level, do some configuration and external features of the use of work, but the two core modules working principle and operational mechanism of understanding, to understand the spring platform in depth, are essential because they are also the basis for the implementation of other spring modules. From the point of view that spring is going to make, that is, from the standpoint of simplifying Java EE Development, it is simply that it is implemented through support for Pojo development, specifically, by providing POJO-based development models for application development and complex Java EE services, decoupling, and improving the coverage of unit tests to effectively improve the overall application development quality. Thus, in fact, it is necessary to provide support for Pojo, various Java EE services to support abstraction into the application platform to encapsulate, and the implementation of this encapsulation function, in spring, is the IOC container and AOP to provide specific, these two modules, to a large extent, Represents the core value of spring as an application development platform. Their realization is rod.johnson in his other book "Expert One-on-one development without EJB," the embodiment of without EJB design thought At the same time, the design concept behind spring is also deeply embodied.

From a deeper point of view, because spring is a Java-based application platform, if we are able to have some understanding of the Java computing model, such as the basic principles of the JVM virtual machine implementation technology, we will have a deeper understanding of the spring implementation, The characteristics of these JVM virtual machines are used, including reflection mechanisms, proxy classes, bytecode technology, and so on. These are some of the underlying technologies of the Java computing environment that are involved in the spring implementation, although for application developers, it may not be directly related to the work of the underlying implementations of these JVM virtual machines, but to understand these background knowledge, more or less, It is very helpful for us to understand the application background of the whole spring platform. For example, as we study in the university, the basic knowledge of computer organization and system, such as digital circuit, computer composition principle, assembly language, operating system and so on these basic courses of learning. Although, frankly speaking, for most of us, the learners of most of our courses may not have much opportunity to work directly on such a low level of technical development in the future, but with these knowledge backgrounds, there is no doubt that we have an in-depth understanding of the application systems based on these basic technologies. With the development of JVM virtual machine technology, it is conceivable that more basic features of virtual machine level will continue to be concerned and adopted by application Platform developers, which is one of the most notable aspects in the process of learning platform implementation, because these underlying technologies are implemented, without a doubt, will have a significant impact on the development roadmap of the spring application platform and the product strategy. At the same time, when using spring as an application platform, if you need deeper development and performance tuning, these underlying knowledge is an integral part of our knowledge base. With these underlying knowledge and understanding of the whole system, there should be little obstacle to wanting to come.

A little understanding of the IOC
The understanding of the spring IOC is inseparable from the understanding of the dependency reversal pattern, and we know that it is an effective solution to solve the complexity of object-oriented system design and to improve the testability of object-oriented system by reversing the control of dependence and transferring control from the specific business object to the platform or framework. This issue has triggered the development of the IOC design pattern and is a central issue for IOC containers to solve. At the same time, the impetus for the emergence of a product-driven IOC container. And I think spring's IOC container is an open source product that implements a dependency reversal pattern.

What exactly is the IOC container? What it looks like in the spring framework. Speaking so much, in fact, for the users of the IOC container, the beanfactory and applicationcontext that we often touch can be seen as concrete representations of the container. These are the IOC containers, or the IOC container in spring, which, from the implementation, refers to a series of containers. That is to say, what we usually call the IOC container, if it goes deep into the implementation of spring, will find that the IOC container actually represents a series of different functional container products. But the function of the container is very small, has its own characteristics. For example, it is like a department store sale of goods, we give a bucket for instance, in the store sold buckets are large and small, the production materials are different, metal, plastic and so on, in short, all kinds, but as long as the water, with the basic characteristics of the bucket, it can be sold as a bucket to let users use. This is the same in spring, it has a wide range of IOC container implementations for users to select and use, and what kind of container is entirely dependent on the user's needs, but before use, if you can understand the basic situation of the container, it will be very helpful to use the container , as we did when we purchased the goods.

We look at the most basic xmlbeanfactory, which is the bottom-level implementation of the container family, which has a very obvious feature compared to the contexts we use in spring applications, and it provides only the most basic functions of the IOC container. As can be seen from its name, this IOC container can read beandefinition defined in XML form. Understanding this helps us to understand the difference and connection between ApplicationContext and the basic beanfactory. We can assume that the direct beanfactory implementation is the basic form of the IOC container, and that the implementation of the various applicationcontext is a high-level representation of the IOC container.

Read the source of the xmlbeanfactory carefully, in the beginning of the comments have a brief description of the function of Xmlbeanfactory, from the code comments can also be seen, this is Rod Johnson in 2001 wrote the Code, It can be seen that this class should be the spring's elder class. It inherits the class of Defaultlistablebeanfactory, and this defaultlistablebeanfactory is a very notable container.

Java code public class Xmlbeanfactory extends Defaultlistablebeanfactory {private final xmlbeandefinitionreader read       ER = new Xmlbeandefinitionreader (this);       Public xmlbeanfactory (Resource Resource) throws Beansexception {This (Resource, null); } public Xmlbeanfactory (Resource Resource, Beanfactory parentbeanfactory) throws beansexception {Super (PA           Rentbeanfactory);       This.reader.loadBeanDefinitions (Resource); }   }


The function of Xmlbeanfactory is based on the basic container of defaultlistablebeanfactory, which implements additional functions such as XML reading on the basis of this basic container. For the implementation of these features, take a look at the Xmlbeanfactory code implementation can be very easy to understand. As you can see in the following code, you need to get the resource object in the Xmlbeanfactory construction method. The initialization of the Xmlbeandefinitionreader object, and the use of this object to complete the loadbeandefinitions call, is that this call initiates the process of loading beandefinitions from resource. This loadbeandefinitions is also an important part of the IOC container initialization.

To put it simply, the initialization of the IOC container includes the three basic processes of beandefinition resouce positioning, loading, and registration. I think the focus is on the process of loading and parsing beandefinition. You can start with defaultlistablebeanfactory to see how the IOC container completes beandefinition loading. After the refresh call is complete, you can see the loaddefinition call:

Java Code    public abstract class abstractxmlapplicationcontext extends  abstractrefreshableconfigapplicationcontext {       public  Abstractxmlapplicationcontext ()  {       }        public abstractxmlapplicationcontext (applicationcontext parent)  {            super (parent);       }        //here is the place to implement Loadbeandefinitions        protected void  Loadbeandefinitions (defaultlistablebeanfactory beanfactory)  throws IOException {            // Create a new  xmlbeandefinitionreader for the given beanfactory.            //  Create  xmlbeandefinitionrEader, and with the callback set to  beanfactory, the creation of Beanfactory is also  defaultlistablebeanfactory.            xmlbeandefinitionreader beandefinitionreader  = new xmlbeandefinitionreader (beanfactory);               // configure the bean definition reader with this  context ' s           // resource loading  environment.           //  Settings here   xmlbeandefinitionreader,  configures the Resourceloader for xmlbeandefinitionreader  because Defaultresourceloader is the parent class, So this can be used directly             Beandefinitionreader.setresourceloader (this);            Beandefinitionreader.setentityresolver (New resourceentityresolver (this));    &nbsP         // Allow a subclass to provide  custom initialization of the reader,            // then proceed with actually loading the bean definitions.        //  This is the process of loading the boot bean definition information             initbeandefinitionreader (beandefinitionreader);            loadbeandefinitions (Beandefinitionreader);       }           protected void initbeandefinitionreader (xmlbeandefinitionreader  Beandefinitionreader)  {       }  
Here, Xmlbeandefinitionreader is used to load beandefinition into the container, as shown in the following code listing:

Java code        //here is the entrance to the call.        public int loadbeandefinitions (Resource resource)   throws beandefinitionstoreexception {            Return loadbeandefinitions (New encodedresource (Resource));       }        //here is where the beandefinition is loaded in XML form.        public int loadbeandefinitions (encodedresource  Encodedresource)  throws BeanDefinitionStoreException {            assert.notnull (encodedresource,  "encodedresource must not be  Null ");           if  (logger.isinfoenabled ())  {                logger.info ("Loading  Xml bean definitions from  " + encodedresource.getresource ());            }              Set< Encodedresource> currentresources = this.resourcescurrentlybeingloaded.get ();           if  (currentresources == null)  {