Shulou(Shulou.com)06/01 Report--

This article will explain in detail what are the BeanDefinition inheritance and container expansion points. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

1.7 Bean Definition inheritance

The bean definition contains some configuration information, including constructor parameters, property values, and container-specific information, such as initialization methods, static factory method names, and so on. The child bean definition inherits the parent bean definition configuration data. Child bean definitions can override some values or add other needs. Some types can be saved using parent bean and child bean definitions. In fact, this is a template mode.

If your programmer uses the ApplicationContext interface, the sub-bean definition is described by the ChildBeanDefinition class. Most users do not use it at this level (Note: application developers generally do not touch it). Instead, they declaratively configure bean definitions in classes such as ClassPathXmlApplicationContext. When you use XML-based configuration metadata, you can specify parent bean as the value of this property by using the parent attribute to indicate the definition of a child bean. The following example shows how to do this:

If not specified, the child bean definition uses the bean class in the parent definition, but it can also be overridden. In the latter case, the child bean class must be compatible with the parent bean definition (that is, the property value of the parent bean must be accepted).

The child bean defines inheritance scope, construction parameter values, property values, and override parent class methods, and can add new values. Any scope, initialization method, destroy method, or static factory method setting overrides the corresponding parent bean setting.

The rest of the settings are always taken from the child bean definition: dependency, autoassembly, dependency checking, singleton, and lazy loading.

The previous example acts as an abstraction by using the abstract attribute to display the tag parent bean definition. If the parent bean definition does not specify a class, it is necessary to explicitly mark the parent bean definition as abstract, as shown in the following example:

The parent bean cannot be instantiated because it is incomplete and it is marked as abstract. When a definition is abstract, it simply serves as a template for a bean definition and the parent bean definition defines the service as the child bean. Trying to use such an abstract parent bean yourself will return an error by referencing it as the ref property of another bean or by making an explicit getBean () call using the parent bean ID. Similarly, the container's internal preInstantiateSingletons () method ignores bean definitions that are defined as abstract.

By default, ApplicationContext pre-instantiates all singletons. Therefore, it is important (at least for singleton bean) that if there is a (parent) bean definition intended only as a template, and this definition specifies a class, you must ensure that the abstract property is set to true, otherwise the application context will actually (attempt) pre-instantiate the abstract Bean.

Reference example: com.liyong.ioccontainer.starter.XmlBeanDefinitionInheritanceContainer

1.8 Container expansion Point

Typically, application developers do not need to implement ApplicationContext classes. Instead, the Spring IoC container extends through the plug-in implementation of the specified integration interface. The following sections describe the integration of these interfaces.

1.8.1 customize bean by using BeanPostProcessor

The BeanPostProcessor interface defines callback methods, which you can implement to provide your own (or override the container's default settings) initialization logic, dependency parsing logic, and so on. If you want to implement some custom logic, after the Spring container has instantiated, configured, and initialized bean, you can insert one or more custom BeanPostProcessor implementations.

You can configure multiple BeanPostProcessor instances and you can control the execution order of these BeanPostProcessor instances by setting the order property. This property can be set only when BeanPostProcessor implements the Ordered interface. If you implement BeanPostProcessor yourself, you should consider implementing the Ordered interface. For more details, see the BeanPostProcessor and Ordered interfaces. See instructions on registering BeanPostProcessor instances programmatically.

The BeanPostProcessor interface operates on the bean (object) instance. That is, the Spring IoC container instantiates a bean instance, and then the BeanPostProcessor instance performs their work. (note: perform relevant callback operations during Spring container initialization of bean)

BeanPostProcessor instances are scoped by container. It only makes sense to use inheritance containers. If you define BeanPostProcessor in a container, only the bean in that container is post-processed. In other words, bean defined in one container will not be processed by BeanPostProcessor defined in other containers, even if both containers belong to the same hierarchy.

To change the actual bean definition (that is, the blueprint that defines bean), you need to use BeanFactoryPostProcessor, as described in using BeanFactoryPostProcessor Custom configuration metadata.

The org.springframework.beans.factory.config.BeanPostProcessor interface happens to consist of two callback methods. When a class is registered with the container as a postprocessing, for each bean instance created by the container, the postprocessor gets a callback after any bean initialization callback before the container initialization method (for example, InitializingBean.afterPropertiesSet () or any declared init method) is called. The post processor can handle any operation of the bean instance, including ignoring all callbacks. The Bean post-processor usually checks the callback interface, or you can wrap the Bean with a proxy. Implement the post-processing of bean in the Spring AOP infrastructure class to provide a proxy wrapper logic.

ApplicationContext automatically checks all bean, which implement the BeanPostProcessor interface in the configuration metadata. ApplicationContext registers these bean as post-processors so that they can be called later when the bean is created. Bean post-processors can be deployed in containers in the same way as other bean.

Note that when you declare BeanPostProcessor by using the @ Bean factory method on a class, the factory method return type should be implementing the class itself or simply implementing the org.springframework.beans.factory.config.BeanPostProcessor interface, clearly indicating the post-processor nature of the bean. Otherwise, ApplicationContext cannot automatically detect it by type before it is fully created. This early type detection is critical because BeanPostProcessor needs to be instantiated early before it can be applied to the initialization of other bean in the context.

Programmatically register BeanPostProcessor instances

The recommended ways to register BeanPostProcessor are automatically detected by ApplicationContext (described earlier), and you can register them programmatically for ConfigurableBeanFactory using the addBeanPostProcessor method. This is useful when you need to evaluate conditional logic or even copy post processors across hierarchical contexts before registering. Note, however, that the addition of BeanPostProcessor instance programmers does not follow the Ordered sorting interface. Here, the order of registration determines the order of execution. It is important to note that programmatic registered BeanPostProcessor instances are always processed after these automatically detected post-processors, regardless of the order in which they are displayed.

BeanPostProcessor instance and AOP Custom Agent

The classes that implement the BeanPostProcessor interface are special, and the container handles them differently. All BeanPostProcessor instances and Bean that they directly reference are instantiated at startup as part of the special startup phase of ApplicationContext. Next, register all BeanPostProcessor instances in a sorted manner and apply them to all other bean in the container. Because AOP auto-proxies are implemented as BeanPostProcessor itself, neither BeanPostProcessor instances nor the bean they refer directly to are suitable for automatic proxies, so there is no weaving aspect.

For any such bean, you should check the log messages:

Bean someBean is not eligible for getting processed by all BeanPostProcessor interfaces (for example: not eligible for auto-proxying).

If you have injected bean into BeanPostProcessor by using autoassembly or @ Resource injection (which may fall back to autoassembly), Spring may access unexpected Bean when searching for dependency candidates of matching types, making them unsuitable for automatic proxy or other types of Bean post-processing. For example, if you have a dependency annotated with @ Resource, where the field or Setter name does not directly correspond to the declared name of bean, and does not use the name attribute, then Spring will access other bean to match them by type.

The following example shows how to write, register, and use the BeanPostProcessor interface in ApplicationContext.

Example: Hello World

The first example illustrates the use of basics. This example shows a custom BeanPostProcessor implementation and calls the toString () method of each bean created through the container and prints the resulting string to the console.

The following listing shows the custom BeanPostProcessor implementation class definition:

Package scripting;import org.springframework.beans.factory.config.BeanPostProcessor;public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {/ / simply return the instantiated bean as-is public Object postProcessBeforeInitialization (Object bean, String beanName) {return bean; / / we could potentially return any object reference here... } public Object postProcessAfterInitialization (Object bean, String beanName) {/ / print bean information System.out.println ("Bean'" + beanName + "'created:" + bean.toString ()); return bean;}}

The following beans elements use InstantiationTracingBeanPostProcessor:

Note how to define InstantiationTracingBeanPostProcessor. It doesn't even have a name, and it's a bean that can be injected into dependencies like other bean. (the previous configuration also defines a bean supported by Groovy scripts. The details of Spring dynamic language support are in the "dynamic language support" chapter.)

The following Java application runs the previous code and configuration:

Import org.springframework.context.ApplicationContext;import org.springframework.context.support.ClassPathXmlApplicationContext;import org.springframework.scripting.Messenger;public final class Boot {public static void main (final String [] args) throws Exception {ApplicationContext ctx = new ClassPathXmlApplicationContext ("scripting/beans.xml"); Messenger messenger = ctx.getBean ("messenger", Messenger.class); System.out.println (messenger);}}

The output of the previous application is similar to the following:

Bean 'messenger' created: org.springframework.scripting.groovy.GroovyMessenger@272961org.springframework.scripting.groovy.GroovyMessenger@272961

Example: RequiredAnnotationBeanPostProcessor

Using the callback interface or in conjunction with a custom BeanPostProcessor implementation is a common way to extend the Spring IoC container. Spring's RequiredAnnotationBeanPostProcessor is an example of a BeanPostProcessor implementation included with the Spring distribution that ensures that the JavaBean attribute on the (arbitrary) annotated bean actually (configured to) dependency injects a value. Description: is the commonly used dependency injection.

Reference code: com.liyong.ioccontainer.starter.XmlBeanPostProcessorIocContainer

1.8.2 BeanFactoryPostProcessor Custom configuration metadata

The next expansion point is org.springframework.beans.factory.config.BeanFactoryPostProcessor. The semantics of this interface are similar to BeanPostProcessor, with one important difference: BeanFactoryPostProcessor operates on bean's configuration metadata. That is, the Spring IoC container allows any bean, with the exception of BeanFactoryPostProcessor, to be read by BeanFactoryPostProcessor from configuration metadata and change it.

You can configure multiple BeanFactoryPostProcessor instances, and you can control the order on these BeanFactoryPostProcessor instances by setting the order property. However, this property can only be set if BeanFactoryPostProcessor implements the Ordered interface. If you write your own BeanFactoryPostProcessor, you should consider implementing the Ordered interface. More details about the BeanFactoryPostProcessor and Ordered interfaces.

If you want to change the actual bean instance (that is, this object is created from the configuration metadata), you need to use BeanPostProcessor (described earlier by using BeanPostProcessor to customize the bean). Technically, you can use Bean instances in BeanFactoryPostProcessor (for example, by using BeanFactory.getBean ()), which results in premature initialization of bean, in violation of the standard container life cycle. This can lead to negative effects, such as bypassing post-processing.

Similarly, BeanFactoryPostProcessor instances are divided by container. (it makes sense if you use a hierarchical container.) if you define a BeanFactoryPostProcessor in a container, it only applies to the bean definition in that container. Bean definitions in one container are not post-processed by BeanFactoryPostProcessor in other containers, even if the two containers are at the same level.

The Bean factory post-processor executes automatically when declared in ApplicationContext to apply changes to the configuration metadata that defines the container. Spring includes some predefined factory post processors, such as PropertyOverrideConfigurer and

PropertySourcesPlaceholderConfigurer . You can use a custom BeanFactoryPostProcessor-, for example, to register a custom attribute editor.

ApplicationContext automatically detects any instance bean that is deployed into the container and implements the BeanFactoryPostProcessor interface. Use these bean as bean factory post processors at the right time. You can deploy these post processors like other ban.

As with BeanPostProcessors, you usually do not want to configure BeanFactoryPostProcessors for deferred initialization. If there are no other bean references to Bean (Factory) PostProcessor, the post processor will not be initialized. Therefore, marking it as delayed initialization will be ignored and Bean (Factory) PostProcessor will be initialized ahead of time even if your declared default-lazy-init attribute is true.

Reference code: com.liyong.ioccontainer.starter.XmlBeanFactoryPostProcessorIocContainer

For example: class name replaces PropertySourcesPlaceholderConfigurer

You can use PropertySourcesPlaceholderConfigurer to externalize property values from the bean definition to a separate file using the standard Java attribute format (meaning: bean configuration data can be configured into a separate file). This allows the person deploying the application to customize environment-specific properties, such as database URL and password, without the complexity or risk of modifying the container's main XML definition file.

Consider the following configuration metadata fragments based on XML, where DataSource is defined using placeholder values:

This example shows the property configuration from the externalized Properties file. At run time, PropertySourcesPlaceholderConfigurer applies metadata to replace the property values of DataSource. The value to be replaced is specified as a placeholder in the ${property-name} format, which follows the Ant, log4j, and JSPEL styles.

The real value comes from other files in standard Properties format:

Jdbc.driverClassName=org.hsqldb.jdbcDriverjdbc.url=jdbc:hsqldb:hsql://production:9002jdbc.username=sajdbc.password=root

Therefore, the ${jdbc.username} string is replaced with a value at run time and is also applied to other placeholders that match these key in the properties file. PropertySourcesPlaceholderConfigurer examines most properties defined by Bean and placeholders in attributes. In addition, you can customize the prefixes and suffixes of placeholders.

The context namespace is introduced in Spring2.5, and you can configure a placeholder for a dedicated configuration element. In the location attribute, you can provide one or more location separated by commas, similar to the following example:

PropertySourcesPlaceholderConfigurer doesn't just look for attributes in the Properties you specify. By default, if no property is found in the specified properties file, it checks the Spring Environment property and the regular Java System property again.

You can use PropertySourcesPlaceholderConfigurer to replace the class name, which is sometimes very useful when you have to select a specific implementation class at run time. The following example shows how to do this:

Classpath:com/something/strategy.properties custom.strategy.class=com.something.DefaultStrategy

If the class cannot be resolved to a valid class at run time, the parsing of the bean will fail when the bean is about to be created, that is, during the preInstantiateSingletons () phase of the non-lazy-init bean ApplicationContext.

Reference code: com.liyong.ioccontainer.starter.XmlPropertySourcesPlaceholderConfigurerIocContainer

Example: PropertyOverrideConfigurer

Another bean factory post-processor, PropertyOverrideConfigurer, is similar to PropertySourcesPlaceholderConfigurer, but unlike the latter, the original definition can have the default value of the bean attribute or no value at all. If the overridden properties file does not match the content for some bean properties, the default context definition is used.

Note: the bean definition is not aware of being overwritten, so the overwritten configuration is not immediately in use from the XML definition file. Because of the override mechanism, the last one will be used in the case of multiple PropertyOverrideConfigurer instances corresponding to different values of the same bean property.

Property file configuration format:

BeanName.property=value

The following listing shows an example of formatting:

DataSource.driverClassName=com.mysql.jdbc.DriverdataSource.url=jdbc:mysql:mydb

This sample file can be used with a container definition that contains a bean named dataSource, which has driver and url properties.

Compound property names are also supported, as long as each component of the path (except the final attribute that is overridden) is non-empty (possibly initialized by the constructor). In the following example, the tom property of bean is set only by the sammy property of fred:

Tom.fred.bob.sammy=123

The specified override value is always the text value. They are not translated into bean references. This convention also applies when the original value in the XML bean definition specifies a bean reference.

The context namespace is introduced in Spring2.5 and can be overridden with dedicated configuration elements, similar to the following example:

Reference code: com.liyong.ioccontainer.starter.XmlPropertyOverrideConfigurerIocContainer

1.8.3 FactoryBean custom initialization logic

You can implement the org.springframework.beans.factory.FactoryBean interface for objects that are factories themselves.

This FactoryBean interface is the instantiation logic pluggable point of the Spring IoC container. If you have a complex initialization code that is better expressed in Java than redundant XML, you can create your own FactoryBean, write complex initialization logic in the implementation class, and then insert your custom FactoryBean into the container.

The FactoryBean interface provides three methods:

Object getObject (): returns an instance created by this factory. This instance may be shared, depending on whether the factory returns a singleton or prototype.

Boolean isSingleton (): return true if FactoryBean returns a singleton otherwise false

Class getObjectType (): returns the object type returned by the getObject () method, or null if the type is unknown

FactoryBean concepts and interfaces are used in some places in the Spring framework. Spring has over 50 implementations of FactoryBean interfaces.

When you need to get an actual FactoryBean instance itself from the container instead of the bean generated by it, add an & symbol to the ID of the bean when calling the getBean () method of the bean. Therefore, for a given FactoryBean whose id is myBean, calling getBean ("myBean") on the container will return the resulting bean of FactoryBean, while calling getBean ("& myBean") will return the FactoryBean instance itself.

So much for sharing about BeanDefinition inheritance and container expansion points. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.