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

This article mainly explains "what are the differences between ApplicationContext and XmlBeanFactory". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the differences between ApplicationContext and XmlBeanFactory"?

The difference between ApplicationContext and XmlBeanFactory

Can these speculations still be used in the source code parsing of ApplicationContext? The answer is yes. We talked about the design and implementation of the IOC container before, which is nothing more than two series, one BeanFactory and one ApplicationContext. So what kind of XmlBeanFactory do we see before? Let's take a look at XmlBeanFactory's class diagram first.

XmlBeanFactory inheritance system is XmlBeanFactory-> DefaultListableBeanFactory-> AbstractAutowireCapableBeanFactory-> AbstractBeanFactory-> FactoryBeanRegistrySupport-> DefaultSingletonBeanRegistry-> SimpleAliasRegistry-> AliasRegistry.

Note, however, that XmlBeanFactory extends on top of DefaultListableBeanFactory. In fact, the BeanFactory interface is finally implemented. And our ApplicationContext, it exists as an advanced form of container. The application context adds many other features to the simple container. Why would you say that? Let's take a look at ApplicationContext's class diagram.

It is not difficult to find that ApplicationContext actually implements BeanFactory, but it is clear here that ApplicationContext has done more support.

BeanFactory

BeanFactory is the core of Spring. Many interview questions ask what is Spring? In fact, you can answer directly: Spring is actually a huge package of BeanFactory, of course, it seems a little one-sided, BeanFactory is indeed the core content of Spring.

BeanFactory provides the most basic IOC container functions. About these functions, we can read his source code.

String FACTORY_BEAN_PREFIX = "&"; / * get bean * / Object getBean (String name) throws BeansException; T getBean (String name, Class requiredType) throws BeansException; T getBean (Class requiredType) throws BeansException;Object getBean (String name, Object...) by name Args) throws BeansException;/** * whether it contains bean * / boolean containsBean (String name); / * query whether bean is Singleton type * / boolean isSingleton (String name) throws NoSuchBeanDefinitionException;/** * query whether bean is Prototype type * / boolean isPrototype (String name) throws NoSuchBeanDefinitionException;/** * query whether class type of bean is a specific class type * / boolean isTypeMatch (String name, Class targetType) throws NoSuchBeanDefinitionException / * query the class type of bean * / Class getType (String name) throws NoSuchBeanDefinitionException;/** * query all aliases of bean * / String [] getAliases (String name)

It doesn't really have much code, but it provides specifications for using IOC containers. Understanding this will help us understand ApplicationContext. We can directly think of BeanFactory as a simple container form and ApplicationContext as an advanced container form.

So far, we have actually seen some differences between XmlBeanFactory and ApplicationContext. But it's not that obvious here. We might as well take a look at the ApplicationContext implementation class ClassPathXmlApplicationContext, which is used in our code. What's the difference between its source code and XmlBeanFactory?

ClassPathXmlApplicationContextpublic ClassPathXmlApplicationContext (String [] configLocations, boolean refresh, @ Nullable ApplicationContext parent) throws BeansException {super (parent); this.setConfigLocations (configLocations); if (refresh) {this.refresh ();}}

Its initialization keeps calling super (parent), but the refresh () method completes the initialization of the container.

The implementation code of the refresh () method is as follows: public void refresh () throws BeansException, IllegalStateException {synchronized (this.startupShutdownMonitor) {this.prepareRefresh (); / preparation ConfigurableListableBeanFactory beanFactory = this.obtainFreshBeanFactory (); / / the ultimate goal of obtaining ConfigurableListableBeanFactory is DefaultListableBeanFactory this.prepareBeanFactory (beanFactory); / / prepare bean factory try {this.postProcessBeanFactory (beanFactory) / / an empty implementation, note that the spring version number here is 5.3x this.invokeBeanFactoryPostProcessors (beanFactory); / / the factory that registers bean this.registerBeanPostProcessors (beanFactory); this.initMessageSource (); / / Spring extracts BeanPostProcessor from all @ Bean definitions and registers them into beanPostProcessors, waiting for subsequent sequential calls to register BeanPostProcessor this.initApplicationEventMulticaster () / / initialize the event listener this.onRefresh (); / / an empty implementation this.registerListeners (); / / register the listener this.finishBeanFactoryInitialization (beanFactory); / / when it comes to the most complex step of the spring loading process, start instantiating all bd this.finishRefresh () / / refresh completed work} catch (BeansException var9) {if (this.logger.isWarnEnabled ()) {this.logger.warn ("Exception encountered during context initialization-cancelling refresh attempt:" + var9);} this.destroyBeans (); this.cancelRefresh (var9); throw var9;} finally {this.resetCommonCaches () }}}

On the whole, the method is relatively clear and highly summarizes what refresh () has done in several big ways. We will interpret these processes in detail later, and here is only a summary.

At this location, we see a process of ClassPathXmlApplicationContext, which is quite different from our XmlBeanFactory. In our previous conjecture, he should load xml first. In fact, it is also done here, but it is hidden deeply. In the specific content of the second part of this loading process, let's post the core code here.

ConfigurableListableBeanFactory beanFactory = this.obtainFreshBeanFactory (); this.refreshBeanFactory (); this.loadBeanDefinitions (beanFactory); protected void loadBeanDefinitions (DefaultListableBeanFactory beanFactory) throws BeansException, IOException {XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader (beanFactory); beanDefinitionReader.setEnvironment (this.getEnvironment ()); beanDefinitionReader.setResourceLoader (this); beanDefinitionReader.setEntityResolver (new ResourceEntityResolver (this)); this.initBeanDefinitionReader (beanDefinitionReader); this.loadBeanDefinitions (beanDefinitionReader);}

In fact, bean initialization and container initialization are all withdrawn in this process, which we will talk about later, but from our summary, it is actually different from our guess, but there are just a lot of other things. These extra things are exactly the difference between our two container implementations.

Summary:

The basic implementation of BeanFactory provides a basic IOC container, and ApplicaitonContext appears in an advanced form, adding a lot of additional functionality.

XmlBeanFactory is one of the most basic applications of our BeanFactory

Both XmlBeanFactory and ClassPathXmlApplicationContext have the process we speculated, but the implementation is different, and there is a big difference in the specific process.

Thank you for your reading, the above is the content of "what are the differences between ApplicationContext and XmlBeanFactory". After the study of this article, I believe you have a deeper understanding of the difference between ApplicationContext and XmlBeanFactory, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.