Spring IoC container instantiation bean method and requestcontextlistener Application

The Spring IoC container instantiates bean in the following ways:

 

Singleton only has one bean instance in the Spring IoC container, and the bean exists as a single instance.

Each time prototype calls bean from the container, a new instance is returned, that is, every time getbean () is called, the operation of new xxxbean () is executed.

Each HTTP request creates a new bean. This scope is only applicable to the webapplicationcontext environment.

A session shares a bean with an http session. Different HTTP sessions use different beans. This scope is only applicable to the webapplicationcontext environment.

Globalsession shares a bean with a global session and is generally used in the Portlet application environment. This scope is only applicable to the webapplicationcontext environment.

 

 

In earlier versions of spring, because there are only two bean scopes, the singleton = "True | false" configuration method is adopted. spring2.0 still supports this configuration method for backward compatibility. however, spring2.0 recommends a new configuration method: Scope = "<scope type> ;"

-------------------------------------------------

Singleton Scope

Spring provides the natural single-instance mode function in the form of containers. Any pojo does not need to write special code and only needs to be configured.

Note: Spring defines the bean's default scope as Singleton.

Singleton example:

<Bean id = "car" class = "com. baobaotao. Scope. Car" Scope = "Singleton"/>

<Bean id = "boss1" class = "com. baobaotao. Scope. Boss">

<Property name = "car" ref = "car"/>

</Bean>

Car bean is declared as Singleton (because it is Singleton by default, it can be explicitly specified ).

By default, when the spring applicationcontext container is started, all Singleton beans are automatically instantiated and cached in the container.

Although it takes some time to start, it brings two advantages: first, the bean instantiation operation in advance will detect some potential configuration problems as soon as possible.

Second, the bean is saved as a cache. When this bean is used during runtime, it does not need to be instantiated any more, accelerating the running efficiency. If you do not want

The bean of Singleton is instantiated in advance when the device starts. You can control the bean by using the lazy-init attribute:

 

<Bean id = "boos1" class = "com. baobaotao. Scope. Boss" lazy-init = "true">

<Property name = "car" ref = "car"/>

</Bean>

The bean of lazy-init = "true" will still be instantiated in advance in some cases: if the bean is referenced by other beans that need to be instantiated in advance,

Spring will also ignore the delayed instantiation settings.

-------------------------------------------------

Prototype Scope

 

Scope = "prototype" is used to specify a bean with a non-single instance scope. For details, see:

<Bean id = "car" class = "com. baobaotao. Scope. Car" Scope = "prototype"/>

<Bean id = "boss1" class = "com. baobaotao. Scope. Boss">

<Property name = "car" ref = "car"/>

</Bean>

<Bean id = "boss2" class = "com. baobaotao. Scope. Boss">

<Property name = "car" ref = "car"/>

</Bean>

Boss1 and boss2 all reference an independent car instance.

By default, the spring container does not instantiate the prototype bean at startup. In addition, the spring container delivers the prototype bean to the call.

Then, it will no longer manage its lifecycle.

-------------------------------------------------

Bean scopes related to Web application environments

 

If you use spring's webapplicationcontext, you can use the other three bean scopes: request, session, and globalsession. However

Before using these scopes, you must first make some additional configurations in the Web Container. In the high-version Web Container, you can use the HTTP request listener for configuration:

<Web-app>

...

<Listener>

<Listener-class>

Org. springframework. Web. Context. Request. requestcontextlistener

</Listener-class>

</Listener>

...

</Web-app>

A careful friend may have a question: when introducing webapplicationcontext initialization, we have used contextloaderlistener

Why is an additional requestcontextlistener introduced here to support the other three scopes of bean?

Contextloaderlistener is used to integrate Spring containers. It implements the servletcontextlistener listener interface and servletcontextlistener.

Only listens for Web Container startup and shutdown events. While requestcontextlistener implements the servletrequestlistener listener interface, this listener listens

HTTP request event. Each request received by the Web server notifies the listener.

The spring container startup and shutdown operations are triggered by the Web Container startup and shutdown events. However, if the bean in the spring container needs to request, session, globalsession

For scope support, the spring container itself must obtain the HTTP request event of the Web Container, and use the HTTP request event to "Drive" the bean scope control logic.

 

Request Scope

As the name suggests, the bean in the request scope corresponds to an HTTP request and lifecycle. Consider the following Configuration:

<Bean name = "car" class = "com. baobaotao. Scope. Car" Scope = "request"/>

In this way, each time the HTTP request calls the car bean, the spring container creates a new car bean. After the request is processed, the bean is destroyed.

 

Session Scope

Assume that the scope of the above car is adjusted to the session type:

<Bean name = "car" class = "com. baobaotao. Scope. Car" Scope = "session"/>

After this configuration, the car bean scope spans the entire http session, and all HTTP requests in the session share the same car bean. When the http session ends, the instance

Is destroyed.

 

Globalsession Scope

The following configuration snippet sets the car scope to globalsession:

<Bean name = "logincontroller" class = "com. baobaotao. Scope. Car" Scope = "globalsession"/>

The globalsession scope is similar to the session scope. However, only the. Portlet specification is used in the Web applications of the Portlet to define the global session concept.

All sub-Portlet sharing of Web applications. If the sub-Portlet is not in the Portlet web application environment, globalsession is naturally equivalent to session as a domain.