single case design of spring container-applicationcontext
Each time a ApplicationContext container is created through new, the Refresh method is executed, and the source code knows that the Refresh method reloads the configuration file. And this created container object holds a map collection of all singleton type beans to implement the singleton, and the life cycle of the map object is the same as the life cycle of the container object
If we pass the new container object every time, we have to rebuild the singleton bean collection every time we reload the configuration file, so that the so-called Singleton will lose its meaning.
In the actual application, the ApplicationContext container object is either a new one every time it is started, or I create a good one ApplicationContext container object beforehand, and save it to a certain place, And I'm going to use it when I need this container (just like requestprocessor in struts, which is ultimately controlled by ServletContext)
In Web application development, we can put the launch of the ApplicationContext container in the initialization of the Web container, so that the spring container is stored in the Web container (ServletContext) and is removed when applied.
In an ordinary application, it is necessary to implement the custom code, the simplest way is to use a singleton class to encapsulate the ApplicationContext container.
Users are using spring to configure n multiple beans. In the Web, the acquisition of spring beans often requires applicationcontext objects, or webapplicationcontextutils classes, which require the user's code within the management of spring, Out of the scope of spring management, although these beans exist in your project, but you can't access them.
Single case design of spring container-applicationcontext