How do core components work together

Beans are the key element in Spring, but what about Context and Core? If Bean is an actor in a show, then Context is the stage background of the show, and Core is the prop. Only together can they have the rudiments of a good show. Of course, the most basic conditions can not make the show stand out, but also his performance of the program is good enough, these programs are the features that Spring can provide.

We know that beans wrap objects, and objects must have data. How to provide a living environment for these data is the problem to be solved by Context. For Context, it is to discover the relationship between each Bean, establish such relationship for them and maintain such relationship. So the Context is a collection of Bean relationships, also known as the Ioc container, and once the Ioc container is set up Spring can work for you. So where does the Core component come in? Core is the list of tools needed to discover, establish, and maintain the relationships between each Bean. In this sense, the Core component is better known as Util.

Between them can be shown in the following figure:

Details of core components

Here you’ll look in detail at the hierarchy of classes within each component and how they are sequenced at runtime. We should be careful where we use Spring.

Bean component

Having explained the importance of the Bean component to Spring, let’s take a look at how the Bean component is designed. Bean component in the Spring of org. Springframework. Beans package. All the classes under this package address three main things: the definition of beans, the creation of beans, and the resolution of beans. The only concern for Spring users is the creation of beans; the other two are done internally and are transparent to you.

Spring beans are created in a typical factory pattern. The top-level interface is BeanFactory. Here is the inheritance hierarchy of this factory:

 

There are three subclasses: the BeanFactory ListableBeanFactory, HierarchicalBeanFactory and AutowireCapableBeanFactory. But from the above we can see the final default implementation class is DefaultListableBeanFactory, achieved all of the interface. So why define so many layers of interfaces? A review of the source code and descriptions of these interfaces reveals that each of them is used to distinguish between restrictions on data access to objects during the transfer and transformation of objects within Spring. For example, the ListableBeanFactory interface indicates that these beans are listable, while the beans represented by HierarchicalBeanFactory are inherited, meaning that each Bean may have a parent Bean. AutowireCapableBeanFactory interface definition of the Bean assembly rules automatically. Together, these four interfaces define collections of beans, relationships between beans, and Bean behavior.

BeanDefinition: BeanDefinition: BeanDefinition: BeanDefinition: BeanDefinition

 

The definition of a Bean is a complete description of all the information in the node you define in the Spring configuration file, including each sub-node. When Spring successfully resolves a node you defined, it is converted to a BeanDefinition object inside Spring. All subsequent operations are done on this object.

The Bean parsing process is very complex, and the functionality is very granular, because there is a lot of scope to extend, and there must be enough flexibility to deal with possible changes. Bean parsing is primarily about parsing Spring configuration files. This parsing process is done with the following classes:

The parser class for the Bean

Of course, there are specific parsing of tags that are not listed here.

The Context components

Context in the Spring of org. Springframework. The Context under the package, it has already been explained the role of Context in the Spring component, he is in fact to Spring provides a runtime environment, to save the state of each object. Let’s take a look at how this environment is built.

ApplicationContext is the top-level superclass of Context. In addition to identifying the basic information of an application environment, ApplicationContext inherits five interfaces, which mainly extend the functions of Context. Here is the class structure of Context:

In addition, ApplicationContext inherits the ResourceLoader interface from the BeanFactory interface. In addition, ApplicationContext inherits the ResourceLoader interface from the BeanFactory interface. Make the ApplicationContext accessible to any external resource, which is explained in detail in Core.

Subclasses of ApplicationContext contain two main aspects:

  1. ConfigurableApplicationContext said the Context can be modified, which is in building the Context of the user can dynamically add or modify an existing configuration information, and below it has multiple subclasses, one of the most frequently used is updatable Context, Namely AbstractRefreshableApplicationContext class.
  2. WebApplicationContext is, as the name suggests, a Context for the Web that has direct access to the ServletContext, which is generally a little-used interface.

The next step is the type of file in which the Context is built, and then the way that Context is accessed. These levels form the complete Context level hierarchy.

In general, ApplicationContext must do several things:

  • Identify an application environment
  • Use BeanFactory to create Bean objects
  • Saves the object relational table
  • The ability to capture various events

Context, as Spring’s Ioc container, basically integrates most of Spring’s functions, or is the basis for most functions.

The Core components

As the Core component of Spring, the Core component contains many key classes, one of which is the definition of resource access mode. This abstraction of all resources into a single interface is well worth learning in future designs. It’s important to look at how this section works in Spring.

Here is a diagram of the class structure related to Resource:

As you can see from the figure above, the Resource interface encapsulates the various possible Resource types, thus masking the differences in file types from the consumer. It’s also a problem for Resource providers to wrap resources and give them to others. We see that the Resource interface inherits from the InputStreamSource interface, which has a getInputStream method that returns the InputStream class. In this way, all resources can be obtained through the InputStream class, so the resource provider is also blocked. In addition, there is the problem of loading resources, that is, the loader of resources should be unified. As can be seen from the figure above, this task is completed by the ResourceLoader interface, which hides all the differences of resource loaders. All resources can be loaded only by implementing this interface. Its default implementation is DefaultResourceLoader.

Now, how do Context and Resource relate to each other? First take a look at their class diagram:

As you can see from the figure above, Context delegates the load, resolution, and description of resources to the ResourcePatternResolver class. It acts as a connector, which integrates the load, resolution, and definition of resources for other components to use. There are many similar ways in Core components.

The Overall Architecture of Spring (part 1)

How the Ioc Container works and extends in # Spring (part 3)

Original address :blog.51cto.com/u_15127644/…