Це може бути корисне для визначення бінів, що перетинають декілька XML файлів. Часто кожний окремий файл XML конфігурації предсатвляє логічний рівень або модуль в вашій архитектурі.

Ви можете використовувати конструктор контексту застосування, щоб завантажити визначення бін з усіх ціх XML фрагментів. Цей конструктор приймає декілька локацій Resource, як показане в попередньому розділі. Альтернативно, використовуйте один або більше елементів <import/> для завантаження визначень бінів з іншого файла або файлів. Наприклад:

В попередньому прикладі зовнішні визначення бінів завантажуються з трьох файлів: services.xml,  messageSource.xmlта themeSource.xml. Всі шляхи розташування відносні до файлу визначення, що робить імпорт, так що services.xml має бути в тому самому каталозі або по classpath, що і файл, який робить імпорт, доки messageSource.xml та themeSource.xml мають бути в розташуванніresources під каталогом, де знаходиться імпортуючий файл. Як ви можете бачити, передуюча коса ігнорується, але беручи, що ці шляхі відносні, краще не використовувати косі взагалі. Вміст файлів буде імпортований, включаючи верхньорівневий елемент <beans/>, має бути валідним XML визначенням бінів, відповідно до Spring Schema.

Директива імпорту в можливістю, що провадиться самим простором імен бінів. Подальші можливості конфігурації за межами плаского визначення бінів доступні в розділі просторів імен XML, що провадить Spring, а саме, просторах імен "context" та "util".

Як подальший приклад розширення метаданих кофігурації, визначення бінів може бути також виражені в Spring Groovy Bean Definition DSL, який відомий з фреймворку Grails. Типово, така конфігурація буде жити в файлі ".groovy" з наступною структурою:

Цей стиль конфігурації в великій мірі еквівалентний до XML бін дефініцій, та навіть підтримує простори імен конфігурації Spring XML. Він також дозволяє імпорт XML файлів бін дефініцій через директиву "importBeans".

В самому визначенні біну ви можете задати більше ніж одне ім'я біну, через використання комбінації одного імені в атрибуті id, та любе число імен в атрибуті name. Ці імена можуть бути еквівалентими аліасами до того самого біна, та корисні в деяких ситуаціях, таких, як дозволити кожному компоненту в застосуванні посилатись на загальну залежність, через використання імені біну, що специфічне для до самого компоненту.

Однак вказувати всі імена бінів там, де бін дійсно визначається, не завжди адекватно. Іноді бажано ввести псевдоним для біну, що визначний деінде. Це загальний випадок в великих системах, де конфігурація рознесена по кожній субсистемі, маючи свій особливий набір визнчення об'єктів. В метаданих конфігурації XML ви можете використовувати призначений саме для цього елемент <alias/>.

В цьому випадку бін, що в тому самому контейнері вигладяє як fromName, може також альтернативно використовувати це визначення псевдониму, що посилається як toName.

Наприклад, метадані конфігурації  для субсистеми A може посилатись на DataSource через ім'я subsystemA-dataSource. Метадані конфігурації для субсистеми B може посилатись до DataSource через ім'я subsystemB-dataSource. Коли ми компонуємо головне застосування, що використовує обоє з ціх субсистем, головне застосування посилається на DataSource через ім'я myApp-dataSource. Щоб мати всі три імені до того самого об'єкту, ви додаєте метадані конфігурації MyApp наступні визначення псевдонімів:

Тепер кожний компонент та головне затосування може посилатись на dataSource через ім'я, що унікальне, та гарантовано не перетинається з іншими визначеннями (ефективно утворюючи простір імен), та при цьому посилаються на той самий бін.

Коли ви створюєте бін за допомогою конструктора, можуть використовуватись всі класи, та всі сумісні із Spring. Тобто розроблений клас не має реалізувати жодного окремого інтерфейсу, або бути закодованим в певний способ. Достатньо тільки вказати клас біну. Однак, в залежності від того, який тип IoC ви використовуєте для вказаного біну, ви можете потребувати констуктор по замовчанню (порожній).

Контейнер Spring IoC може крувати віртульно любим класом, який ви бажаєте надати в його розпорядження; це не лемітовано до справжніх JavaBean. Більшість користувачів Spring схиляються до дійсних JavaBeans, з єдиним порожнім конструкором, та відповідними сеттерами та геттерами, змодельованими для властивостей в контейнері. Ви також можете мати більш екзотичні, не-бін-стайл класи, в вашому контейнері. Якщо, наприклад, вам треба використати старий пул з'єднань, що абсолютно не поважає специфікацію JavaBean, Spring зможе керувати цім також.

За допомогою XML конфігурації ви можете вказати цей клас біну таким чином:

Щодо деталей про механізм для надання аргументів до конструктора (якщо вони потрібні), та встановлення властивостей примірника після того, як об'єкт сконструйований, дивіться Ін'єкція залежностей.

Коли визначається бін, який ви створюєте за допомогою статичного метода-фабрики ви використовєте атрибут  class для вказання класу, що містить цей статичний метод, та атрибут factory-methodдля задання самого імені методу. Ви повинні бути в змозі викликати цей метод (з опціональними аргументами, як показано далі), та повернути живий об'єкт, що відповідно трактується, якби він був створений через конструктор. Одне  з використань такого визначення біна є виклик статичної фабрики в старому коді.

Наступне визначення коду вказує, що бін буде створений з використанням статичного метода-фабрики. Визначеня не вказує тип (клас) повернутого об'єкта, тільки клас, що містить метод-фабрику. В цьому прикладі метод createInstance()має бути статичним методом.

За деталями щодо механізму надання (опціональних) аргументів до метода-фабрики та встановлення властивостей примірника, після того, як об'єкт повертаєтсья з фабрики, дивіться Залежності та конфігурація в деталях.

Подібно до створення примірника через статичний метод-фабрику, створення примірника за допомогою метода-фабрики викликає нестатичний метод на існуючому біні з контейнера, щоб створити новий бін. Щоб використати цей механізм залиште атрибут класу пустим, та в атрибуті factory-bean вкажіть ім'я біна в поточному  (або батьківському/дочірньому) контейнері, що містить метод примірника, що буде викликаний для створення об'єкта. Встановіть ім'я фабрики метода-фабрики за допомогою атрибута factory-method.

Один клас-фабрика може містити більше ніж один метод-фабрику, як показано тут:

Цей підхід показує, що сам бін-фабрика може бути керований та сонфігурований через ін'єкцію залежносте (DI). Дивіться Залежності та конфігурація в деталях.

DI на базі конструкторів - це коли контейнер викликає конструктор з декількома аргументами, кожний представляє собою залежність. Виклик статичного метода-фабрики з певними аргументами для конструювання біну майже еквівалентне, та ця дискусія трактує аргументи до конструктора та статичного метода-фабрики подібним чином. Наступний приклад показує клас, що може бути тільки ін'єктований за допомогою ін'єкції конструктора. Зауважте, що тут немає нічого особливого щодо цього класу, це POJO, що не має залежностей від спеціальних інтерфейсів контейнера, базових класів або анотацій.

DI на совнові сеттерів - це коли контейнер викликає методи-сеттери для ваших бінів після виклику конструктора без параметрів, або статичного метода-фабрики, для створення примірника.

Наступний приклад показує клас, що може бути ін'єктований з використанням чистої сеттерної ін'єкції. Цей клас є чистим Java. Це POJO, що не має залежностей від інтерфейсів контейнера, базових класів або анотацій.

ApplicationContext підтримує базований на конструкторах та сеттерах DI для бінів, якими він керує. Він також підтримує сеттер-базований DI після того, як деякі з залежностей вже були ін'єктовані через конструктор. Ви конфігуруєте залежнсоті в формі BeanDefinition, який ви використовуєте разом з примірниками PropertyEditorдля конвертації властивостей з одного формату в інший. Однак більшість користувачів Spring не роблять з ціма класами напряму (тобто програмно), але через визначення XML bean, анотовані компоненти (класи, анотовані як @Component,@Controller, тощо), або методів @Bean в Java-базованих класах @Configuration. Ці джерела потім конвертуються внутрішньо в примірники BeanDefinition, та використовуються для завантаження цілого примірника контейнера Spring IoC.

Контейнер виконує розрішення залежностей бінів наступним чином:

Контейнер Spring перевіряє конфігурацію кожного біна при створені контейнера. Однак самі властивості біна не встановлюються, доки бін не буде насправді створюватись. Біни, що мають область оглядовості синглтона, та встановлюються в перед-визначене значення (по замочанню), створюються при створенні контейнера. Області визначаються в Областях бінів. Інакше бін створюється тільки за потреби. Створення біна потенційно викликає створення графа бінів, бо створюються та присвоюються залежності бінів, та залежності залежностей (і так далі). Зауважте, що неспівпадіння розрішення серед ціх залежностей може виявитись пізно, тобто, при першому створенні задіяного біну.

Загалом ви можете довіряти Spring, що він робить гарні речі. Він детектує проблеми конфігурації, такі, як посилання на неіснючі біни та циклічні залежності, під час завантаження контейнера. Spring встановлює властивості та розрішує залежності так пізно, як це можливо, коли бін насправді створюється. Це означає, що контейнер Spring, загружений коректно, може пізніше генерувати виключення, коли він потребує об'єкт, коли є проблема зі створенням цього об'єкту, або одної з його залежностей. Наприклад, бін викликає виключення як результат недостатньої або невалідної властивості. Це потенційно затримує видимість деяких проблем конфігурації, та тому реалізації ApplicationContext по замовчанню попередньо створюють синглтон-біни. Ціною деякого попереднього часу та пам'яті для створення ціх бінів, до того, як вони дійсно знадобляться, ви знайдете проблеми конфігурації при створенні ApplicationContext, а не пізніше. Ви можете все ще перекрити поведінку по замовчанню, так що біни-синглтони будуть ініціалізовані ліниво, скоріше, ніж заздалегідь.

Якщо циклічних залежності існують, тоді один або більше з колаборуючих бінів вставляються в залежний бін, кожний колаборуючий бін тотально конфігурується до того, як буде вставлений в залежний бін. Це означає, що якщо бін A має залежність від біну B, контейнер Spring IoC повністю конфігурує бін B перед викликом, для виклику метода сеттера на біні A. Іншими словами, бін втілюється (якщо це не попередньо створений синглтон), встанвллються його залежності, та викликаються його відповідні методи життєвого циклу (такі як метод конфігурованої ініціалізації або метод зворотнього виклику InitializingBean).

Наступний приклад використовує XML метадні конфігурації для сеттер-DI. Мала частина є частиною файлу конфігурації  Spring XML, що задає деякі визначення бінів:

В попередньому прикладі сеттери декларовані для співпадіння з властивостями, заданими в файлі XML. Наступний приклад використовує конструктор-DI:

Аргументи конструктора, вказані в визначенні конструктора, будуть використані як аргументи до констурктора ExampleBean.

Тепер розглянемо варіант прикладу, де замість конструктора використовується статичний метод-фабрика, що повертає примірник об'єкту:

Аргументи статичного метода-фабрики передаються через елементи<constructor-arg/>, точно так само, якщо б був використаний конструктор. Тип класу, що повертається фабрикою, не має бути того самого типу, що і клас, що має статичний метод-фабрику, хоча в прикладі це є так. Примірник (нестатичний) метода-фабрики може бути використаний в майже такому ж вигляді (крім використання атрибуту factory-bean замість атрибуту  class), так що деталі не будуть тут розглядатись.

The value attribute of the <property/> element specifies a property or constructor argument as a human-readable string representation. Spring’s conversion service is used to convert these values from a String to the actual type of the property or argument.

The following example uses the p-namespace for even more succinct XML configuration.

The preceding XML is more succinct; however, typos are discovered at runtime rather than design time, unless you use an IDE such as IntelliJ IDEA or the Spring Tool Suite (STS) that support automatic property completion when you create bean definitions. Such IDE assistance is highly recommended.

You can also configure a java.util.Properties instance as:

The Spring container converts the text inside the <value/> element into a java.util.Properties instance by using the JavaBeans PropertyEditor mechanism. This is a nice shortcut, and is one of a few places where the Spring team do favor the use of the nested <value/> element over the value attribute style.

The ref element is the final element inside a <constructor-arg/> or <property/> definition element. Here you set the value of the specified property of a bean to be a reference to another bean (a collaborator) managed by the container. The referenced bean is a dependency of the bean whose property will be set, and it is initialized on demand as needed before the property is set. (If the collaborator is a singleton bean, it may be initialized already by the container.) All references are ultimately a reference to another object. Scoping and validation depend on whether you specify the id/name of the other object through the bean, local, or parent attributes.

Specifying the target bean through the bean attribute of the <ref/> tag is the most general form, and allows creation of a reference to any bean in the same container or parent container, regardless of whether it is in the same XML file. The value of the bean attribute may be the same as the id attribute of the target bean, or as one of the values in the name attribute of the target bean.

Specifying the target bean through the parent attribute creates a reference to a bean that is in a parent container of the current container. The value of the parent attribute may be the same as either the id attribute of the target bean, or one of the values in the name attribute of the target bean, and the target bean must be in a parent container of the current one. You use this bean reference variant mainly when you have a hierarchy of containers and you want to wrap an existing bean in a parent container with a proxy that will have the same name as the parent bean.

A <bean/> element inside the <property/> or <constructor-arg/> elements defines a so-called inner bean.

An inner bean definition does not require a defined id or name; if specified, the container does not use such a value as an identifier. The container also ignores the scope flag on creation: Inner beans are always anonymous and they are alwayscreated with the outer bean. It is not possible to inject inner beans into collaborating beans other than into the enclosing bean or to access them independently.

As a corner case, it is possible to receive destruction callbacks from a custom scope, e.g. for a request-scoped inner bean contained within a singleton bean: The creation of the inner bean instance will be tied to its containing bean, but destruction callbacks allow it to participate in the request scope’s lifecycle. This is not a common scenario; inner beans typically simply share their containing bean’s scope.

In the <list/>, <set/>, <map/>, and <props/> elements, you set the properties and arguments of the Java Collectiontypes List, Set, Map, and Properties, respectively.

The value of a map key or value, or a set value, can also again be any of the following elements:

Spring treats empty arguments for properties and the like as empty Strings. The following XML-based configuration metadata snippet sets the email property to the empty String value ("").

The preceding example is equivalent to the following Java code:

The <null/> element handles null values. For example:

The above configuration is equivalent to the following Java code:

The p-namespace enables you to use the bean element’s attributes, instead of nested <property/> elements, to describe your property values and/or collaborating beans.

Spring supports extensible configuration formats with namespaces, which are based on an XML Schema definition. The beansconfiguration format discussed in this chapter is defined in an XML Schema document. However, the p-namespace is not defined in an XSD file and exists only in the core of Spring.

The following example shows two XML snippets that resolve to the same result: The first uses standard XML format and the second uses the p-namespace.

The example shows an attribute in the p-namespace called email in the bean definition. This tells Spring to include a property declaration. As previously mentioned, the p-namespace does not have a schema definition, so you can set the name of the attribute to the property name.

This next example includes two more bean definitions that both have a reference to another bean:

As you can see, this example includes not only a property value using the p-namespace, but also uses a special format to declare property references. Whereas the first bean definition uses <property name="spouse" ref="jane"/> to create a reference from bean john to bean jane, the second bean definition uses p:spouse-ref="jane" as an attribute to do the exact same thing. In this case spouse is the property name, whereas the -ref part indicates that this is not a straight value but rather a reference to another bean.

Similar to the XML shortcut with the p-namespace, the c-namespace, newly introduced in Spring 3.1, allows usage of inlined attributes for configuring the constructor arguments rather then nested constructor-arg elements.

Let’s review the examples from Constructor-based dependency injection with the c: namespace:

The c: namespace uses the same conventions as the p: one (trailing -ref for bean references) for setting the constructor arguments by their names. And just as well, it needs to be declared even though it is not defined in an XSD schema (but it exists inside the Spring core).

For the rare cases where the constructor argument names are not available (usually if the bytecode was compiled without debugging information), one can use fallback to the argument indexes:

In practice, the constructor resolution mechanism is quite efficient in matching arguments so unless one really needs to, we recommend using the name notation through-out your configuration.

You can use compound or nested property names when you set bean properties, as long as all components of the path except the final property name are not null. Consider the following bean definition.

The foo bean has a fred property, which has a bob property, which has a sammy property, and that final sammy property is being set to the value 123. In order for this to work, the fred property of foo, and the bob property of fred must not benull after the bean is constructed, or a NullPointerException is thrown.

Autowiring works best when it is used consistently across a project. If autowiring is not used in general, it might be confusing to developers to use it to wire only one or two bean definitions.

Consider the limitations and disadvantages of autowiring:

In the latter scenario, you have several options:

On a per-bean basis, you can exclude a bean from autowiring. In Spring’s XML format, set the autowire-candidate attribute of the <bean/> element to false; the container makes that specific bean definition unavailable to the autowiring infrastructure (including annotation style configurations such as @Autowired).

You can also limit autowire candidates based on pattern-matching against bean names. The top-level <beans/> element accepts one or more patterns within its default-autowire-candidates attribute. For example, to limit autowire candidate status to any bean whose name ends with Repository, provide a value of *Repository. To provide multiple patterns, define them in a comma-separated list. An explicit value of true or false for a bean definitions autowire-candidate attribute always takes precedence, and for such beans, the pattern matching rules do not apply.

These techniques are useful for beans that you never want to be injected into other beans by autowiring. It does not mean that an excluded bean cannot itself be configured using autowiring. Rather, the bean itself is not a candidate for autowiring other beans.

Lookup method injection is the ability of the container to override methods on container managed beans, to return the lookup result for another named bean in the container. The lookup typically involves a prototype bean as in the scenario described in the preceding section. The Spring Framework implements this method injection by using bytecode generation from the CGLIB library to generate dynamically a subclass that overrides the method.

Looking at the CommandManager class in the previous code snippet, you see that the Spring container will dynamically override the implementation of the createCommand() method. Your CommandManager class will not have any Spring dependencies, as can be seen in the reworked example:

In the client class containing the method to be injected (the CommandManager in this case), the method to be injected requires a signature of the following form:

If the method is abstract, the dynamically-generated subclass implements the method. Otherwise, the dynamically-generated subclass overrides the concrete method defined in the original class. For example:

The bean identified as commandManager calls its own method createCommand() whenever it needs a new instance of the myCommand bean. You must be careful to deploy the myCommand bean as a prototype, if that is actually what is needed. If it is as a singleton, the same instance of the myCommand bean is returned each time.

Alternatively, within the annotation-based component model, you may declare a lookup method through the @Lookupannotation:

Or, more idiomatically, you may rely on the target bean getting resolved against the declared return type of the lookup method:

Note that you will typically declare such annotated lookup methods with a concrete stub implementation, in order for them to be compatible with Spring’s component scanning rules where abstract classes get ignored by default. This limitation does not apply in case of explicitly registered or explicitly imported bean classes.

A less useful form of method injection than lookup method injection is the ability to replace arbitrary methods in a managed bean with another method implementation. Users may safely skip the rest of this section until the functionality is actually needed.

With XML-based configuration metadata, you can use the replaced-method element to replace an existing method implementation with another, for a deployed bean. Consider the following class, with a method computeValue, which we want to override:

A class implementing the org.springframework.beans.factory.support.MethodReplacer interface provides the new method definition.

The bean definition to deploy the original class and specify the method override would look like this:

You can use one or more contained <arg-type/> elements within the <replaced-method/> element to indicate the method signature of the method being overridden. The signature for the arguments is necessary only if the method is overloaded and multiple variants exist within the class. For convenience, the type string for an argument may be a substring of the fully qualified type name. For example, the following all match java.lang.String:

Because the number of arguments is often enough to distinguish between each possible choice, this shortcut can save a lot of typing, by allowing you to type only the shortest string that will match an argument type.

To support the scoping of beans at the request, session, application, and websocket levels (web-scoped beans), some minor initial configuration is required before you define your beans. (This initial setup is not required for the standard scopes, singleton and prototype.)

How you accomplish this initial setup depends on your particular Servlet environment.

If you access scoped beans within Spring Web MVC, in effect, within a request that is processed by the Spring DispatcherServlet, then no special setup is necessary: DispatcherServlet already exposes all relevant state.

If you use a Servlet 2.5 web container, with requests processed outside of Spring’s DispatcherServlet (for example, when using JSF or Struts), you need to register the org.springframework.web.context.request.RequestContextListenerServletRequestListener. For Servlet 3.0+, this can be done programmatically via the WebApplicationInitializerinterface. Alternatively, or for older containers, add the following declaration to your web application’s web.xml file:

Alternatively, if there are issues with your listener setup, consider using Spring’s RequestContextFilter. The filter mapping depends on the surrounding web application configuration, so you have to change it as appropriate.

DispatcherServlet, RequestContextListener, and RequestContextFilter all do exactly the same thing, namely bind the HTTP request object to the Thread that is servicing that request. This makes beans that are request- and session-scoped available further down the call chain.

Consider the following XML configuration for a bean definition:

The Spring container creates a new instance of the LoginAction bean by using the loginAction bean definition for each and every HTTP request. That is, the loginAction bean is scoped at the HTTP request level. You can change the internal state of the instance that is created as much as you want, because other instances created from the same loginAction bean definition will not see these changes in state; they are particular to an individual request. When the request completes processing, the bean that is scoped to the request is discarded.

When using annotation-driven components or Java Config, the @RequestScope annotation can be used to assign a component to the request scope.

Consider the following XML configuration for a bean definition:

The Spring container creates a new instance of the UserPreferences bean by using the userPreferences bean definition for the lifetime of a single HTTP Session. In other words, the userPreferences bean is effectively scoped at the HTTP Sessionlevel. As with request-scoped beans, you can change the internal state of the instance that is created as much as you want, knowing that other HTTP Session instances that are also using instances created from the same userPreferences bean definition do not see these changes in state, because they are particular to an individual HTTP Session. When the HTTP Session is eventually discarded, the bean that is scoped to that particular HTTP Session is also discarded.

When using annotation-driven components or Java Config, the @SessionScope annotation can be used to assign a component to the session scope.

Consider the following XML configuration for a bean definition:

The Spring container creates a new instance of the AppPreferences bean by using the appPreferences bean definition once for the entire web application. That is, the appPreferences bean is scoped at the ServletContext level, stored as a regularServletContext attribute. This is somewhat similar to a Spring singleton bean but differs in two important ways: It is a singleton per ServletContext, not per Spring 'ApplicationContext' (for which there may be several in any given web application), and it is actually exposed and therefore visible as a ServletContext attribute.

When using annotation-driven components or Java Config, the @ApplicationScope annotation can be used to assign a component to the application scope.

The Spring IoC container manages not only the instantiation of your objects (beans), but also the wiring up of collaborators (or dependencies). If you want to inject (for example) an HTTP request scoped bean into another bean of a longer-lived scope, you may choose to inject an AOP proxy in place of the scoped bean. That is, you need to inject a proxy object that exposes the same public interface as the scoped object but that can also retrieve the real target object from the relevant scope (such as an HTTP request) and delegate method calls onto the real object.

The configuration in the following example is only one line, but it is important to understand the "why" as well as the "how" behind it.

To create such a proxy, you insert a child <aop:scoped-proxy/> element into a scoped bean definition (see Choosing the type of proxy to create and XML Schema-based configuration). Why do definitions of beans scoped at the request, session and custom-scope levels require the <aop:scoped-proxy/> element? Let’s examine the following singleton bean definition and contrast it with what you need to define for the aforementioned scopes (note that the following userPreferences bean definition as it stands is incomplete).

In the preceding example, the singleton bean userManager is injected with a reference to the HTTP Session-scoped bean userPreferences. The salient point here is that the userManager bean is a singleton: it will be instantiated exactly once per container, and its dependencies (in this case only one, the userPreferences bean) are also injected only once. This means that the userManager bean will only operate on the exact same userPreferences object, that is, the one that it was originally injected with.

This is not the behavior you want when injecting a shorter-lived scoped bean into a longer-lived scoped bean, for example injecting an HTTP Session-scoped collaborating bean as a dependency into singleton bean. Rather, you need a single userManager object, and for the lifetime of an HTTP Session, you need a userPreferences object that is specific to said HTTP Session. Thus the container creates an object that exposes the exact same public interface as the UserPreferencesclass (ideally an object that is a UserPreferences instance) which can fetch the real UserPreferences object from the scoping mechanism (HTTP request, Session, etc.). The container injects this proxy object into the userManager bean, which is unaware that this UserPreferences reference is a proxy. In this example, when a UserManager instance invokes a method on the dependency-injected UserPreferences object, it actually is invoking a method on the proxy. The proxy then fetches the real UserPreferences object from (in this case) the HTTP Session, and delegates the method invocation onto the retrieved real UserPreferences object.

Thus you need the following, correct and complete, configuration when injecting request- and session-scoped beans into collaborating objects:

To integrate your custom scope(s) into the Spring container, you need to implement theorg.springframework.beans.factory.config.Scope interface, which is described in this section. For an idea of how to implement your own scopes, see the Scope implementations that are supplied with the Spring Framework itself and the Scopejavadocs, which explains the methods you need to implement in more detail.

The Scope interface has four methods to get objects from the scope, remove them from the scope, and allow them to be destroyed.

The following method returns the object from the underlying scope. The session scope implementation, for example, returns the session-scoped bean (and if it does not exist, the method returns a new instance of the bean, after having bound it to the session for future reference).

The following method removes the object from the underlying scope. The session scope implementation for example, removes the session-scoped bean from the underlying session. The object should be returned, but you can return null if the object with the specified name is not found.

The following method registers the callbacks the scope should execute when it is destroyed or when the specified object in the scope is destroyed. Refer to the javadocs or a Spring scope implementation for more information on destruction callbacks.

The following method obtains the conversation identifier for the underlying scope. This identifier is different for each scope. For a session scoped implementation, this identifier can be the session identifier.

After you write and test one or more custom Scope implementations, you need to make the Spring container aware of your new scope(s). The following method is the central method to register a new Scope with the Spring container:

This method is declared on the ConfigurableBeanFactory interface, which is available on most of the concrete ApplicationContext implementations that ship with Spring via the BeanFactory property.

The first argument to the registerScope(..) method is the unique name associated with a scope; examples of such names in the Spring container itself are singleton and prototype. The second argument to the registerScope(..) method is an actual instance of the custom Scope implementation that you wish to register and use.

Suppose that you write your custom Scope implementation, and then register it as below.

You then create bean definitions that adhere to the scoping rules of your custom Scope:

With a custom Scope implementation, you are not limited to programmatic registration of the scope. You can also do the Scope registration declaratively, using the CustomScopeConfigurer class:

The org.springframework.beans.factory.InitializingBean interface allows a bean to perform initialization work after all necessary properties on the bean have been set by the container. The InitializingBean interface specifies a single method:

It is recommended that you do not use the InitializingBean interface because it unnecessarily couples the code to Spring. Alternatively, use the @PostConstruct annotation or specify a POJO initialization method. In the case of XML-based configuration metadata, you use the init-method attribute to specify the name of the method that has a void no-argument signature. With Java config, you use the initMethod attribute of @Bean, see Receiving lifecycle callbacks. For example, the following:

… ​is exactly the same as…​

but does not couple the code to Spring.

Implementing the org.springframework.beans.factory.DisposableBean interface allows a bean to get a callback when the container containing it is destroyed. The DisposableBean interface specifies a single method:

It is recommended that you do not use the DisposableBean callback interface because it unnecessarily couples the code to Spring. Alternatively, use the @PreDestroy annotation or specify a generic method that is supported by bean definitions. With XML-based configuration metadata, you use the destroy-method attribute on the <bean/>. With Java config, you use the destroyMethod attribute of @Bean, see Receiving lifecycle callbacks. For example, the following definition:

is exactly the same as:

but does not couple the code to Spring.

When you write initialization and destroy method callbacks that do not use the Spring-specific InitializingBean and DisposableBean callback interfaces, you typically write methods with names such as init(), initialize(), dispose(), and so on. Ideally, the names of such lifecycle callback methods are standardized across a project so that all developers use the same method names and ensure consistency.

You can configure the Spring container to look for named initialization and destroy callback method names on every bean. This means that you, as an application developer, can write your application classes and use an initialization callback called init(), without having to configure an init-method="init" attribute with each bean definition. The Spring IoC container calls that method when the bean is created (and in accordance with the standard lifecycle callback contract described previously). This feature also enforces a consistent naming convention for initialization and destroy method callbacks.

Suppose that your initialization callback methods are named init() and destroy callback methods are named destroy(). Your class will resemble the class in the following example.

The presence of the default-init-method attribute on the top-level <beans/> element attribute causes the Spring IoC container to recognize a method called init on beans as the initialization method callback. When a bean is created and assembled, if the bean class has such a method, it is invoked at the appropriate time.

You configure destroy method callbacks similarly (in XML, that is) by using the default-destroy-method attribute on the top-level <beans/> element.

Where existing bean classes already have callback methods that are named at variance with the convention, you can override the default by specifying (in XML, that is) the method name using the init-method and destroy-method attributes of the <bean/> itself.

The Spring container guarantees that a configured initialization callback is called immediately after a bean is supplied with all dependencies. Thus the initialization callback is called on the raw bean reference, which means that AOP interceptors and so forth are not yet applied to the bean. A target bean is fully created first, then an AOP proxy (for example) with its interceptor chain is applied. If the target bean and the proxy are defined separately, your code can even interact with the raw target bean, bypassing the proxy. Hence, it would be inconsistent to apply the interceptors to the init method, because doing so would couple the lifecycle of the target bean with its proxy/interceptors and leave strange semantics when your code interacts directly to the raw target bean.

As of Spring 2.5, you have three options for controlling bean lifecycle behavior: the InitializingBean and DisposableBeancallback interfaces; custom init() and destroy() methods; and the @PostConstruct and @PreDestroy annotations. You can combine these mechanisms to control a given bean.

Multiple lifecycle mechanisms configured for the same bean, with different initialization methods, are called as follows:

Destroy methods are called in the same order:

The Lifecycle interface defines the essential methods for any object that has its own lifecycle requirements (e.g. starts and stops some background process):

Any Spring-managed object may implement that interface. Then, when the ApplicationContext itself receives start and stop signals, e.g. for a stop/restart scenario at runtime, it will cascade those calls to all Lifecycle implementations defined within that context. It does this by delegating to a LifecycleProcessor:

Notice that the LifecycleProcessor is itself an extension of the Lifecycle interface. It also adds two other methods for reacting to the context being refreshed and closed.

The order of startup and shutdown invocations can be important. If a "depends-on" relationship exists between any two objects, the dependent side will start after its dependency, and it will stop before its dependency. However, at times the direct dependencies are unknown. You may only know that objects of a certain type should start prior to objects of another type. In those cases, the SmartLifecycle interface defines another option, namely the getPhase() method as defined on its super-interface, Phased.

When starting, the objects with the lowest phase start first, and when stopping, the reverse order is followed. Therefore, an object that implements SmartLifecycle and whose getPhase() method returns Integer.MIN_VALUE would be among the first to start and the last to stop. At the other end of the spectrum, a phase value of Integer.MAX_VALUE would indicate that the object should be started last and stopped first (likely because it depends on other processes to be running). When considering the phase value, it’s also important to know that the default phase for any "normal" Lifecycle object that does not implement SmartLifecycle would be 0. Therefore, any negative phase value would indicate that an object should start before those standard components (and stop after them), and vice versa for any positive phase value.

As you can see the stop method defined by SmartLifecycle accepts a callback. Any implementation must invoke that callback’s run() method after that implementation’s shutdown process is complete. That enables asynchronous shutdown where necessary since the default implementation of the LifecycleProcessor interface, DefaultLifecycleProcessor, will wait up to its timeout value for the group of objects within each phase to invoke that callback. The default per-phase timeout is 30 seconds. You can override the default lifecycle processor instance by defining a bean named "lifecycleProcessor" within the context. If you only want to modify the timeout, then defining the following would be sufficient:

As mentioned, the LifecycleProcessor interface defines callback methods for the refreshing and closing of the context as well. The latter will simply drive the shutdown process as if stop() had been called explicitly, but it will happen when the context is closing. The 'refresh' callback on the other hand enables another feature of SmartLifecycle beans. When the context is refreshed (after all objects have been instantiated and initialized), that callback will be invoked, and at that point the default lifecycle processor will check the boolean value returned by each SmartLifecycle object’s isAutoStartup() method. If "true", then that object will be started at that point rather than waiting for an explicit invocation of the context’s or its own start() method (unlike the context refresh, the context start does not happen automatically for a standard context implementation). The "phase" value as well as any "depends-on" relationships will determine the startup order in the same way as described above.

If you are using Spring’s IoC container in a non-web application environment; for example, in a rich client desktop environment; you register a shutdown hook with the JVM. Doing so ensures a graceful shutdown and calls the relevant destroy methods on your singleton beans so that all resources are released. Of course, you must still configure and implement these destroy callbacks correctly.

To register a shutdown hook, you call the registerShutdownHook() method that is declared on the ConfigurableApplicationContext interface:

This first example illustrates basic usage. The example shows a custom BeanPostProcessor implementation that invokes the toString() method of each bean as it is created by the container and prints the resulting string to the system console.

Find below the custom BeanPostProcessor implementation class definition:

Notice how the InstantiationTracingBeanPostProcessor is simply defined. It does not even have a name, and because it is a bean it can be dependency-injected just like any other bean. (The preceding configuration also defines a bean that is backed by a Groovy script. The Spring dynamic language support is detailed in the chapter entitled Dynamic language support.)

The following simple Java application executes the preceding code and configuration:

The output of the preceding application resembles the following:

Using callback interfaces or annotations in conjunction with a custom BeanPostProcessor implementation is a common means of extending the Spring IoC container. An example is Spring’s RequiredAnnotationBeanPostProcessor - aBeanPostProcessor implementation that ships with the Spring distribution which ensures that JavaBean properties on beans that are marked with an (arbitrary) annotation are actually (configured to be) dependency-injected with a value.

You use the PropertyPlaceholderConfigurer to externalize property values from a bean definition in a separate file using the standard Java Properties format. Doing so enables the person deploying an application to customize environment-specific properties such as database URLs and passwords, without the complexity or risk of modifying the main XML definition file or files for the container.

Consider the following XML-based configuration metadata fragment, where a DataSource with placeholder values is defined. The example shows properties configured from an external Properties file. At runtime, a PropertyPlaceholderConfigureris applied to the metadata that will replace some properties of the DataSource. The values to replace are specified as placeholders of the form ${property-name} which follows the Ant / log4j / JSP EL style.

The actual values come from another file in the standard Java Properties format:

Therefore, the string ${jdbc.username} is replaced at runtime with the value 'sa', and the same applies for other placeholder values that match keys in the properties file. The PropertyPlaceholderConfigurer checks for placeholders in most properties and attributes of a bean definition. Furthermore, the placeholder prefix and suffix can be customized.

With the context namespace introduced in Spring 2.5, it is possible to configure property placeholders with a dedicated configuration element. One or more locations can be provided as a comma-separated list in the location attribute.

The PropertyPlaceholderConfigurer not only looks for properties in the Properties file you specify. By default it also checks against the Java System properties if it cannot find a property in the specified properties files. You can customize this behavior by setting the systemPropertiesMode property of the configurer with one of the following three supported integer values:

Consult the PropertyPlaceholderConfigurer javadocs for more information.