postprocessor spring что это

Урок 2: Введение в Spring IoC контейнер

Этот урок освещает работу с Spring Framework IoC контейнером и основан на оригинальной документации §5. The IoC container.

Что вы создадите

Вы создадите некоторое количество классов, в которых будет рассмотрена функциональность Spring Framework IoC контейнера.

Что вам потребуется

Настройка проекта

Введение

Inversion of Control (IoC), также известное как Dependency Injection (DI), является процессом, согласно которому объекты определяют свои зависимости, т.е. объекты, с которыми они работают, через аргументы конструктора/фабричного метода или свойства, которые были установлены или возвращены фабричным методом. Затем контейнер inject(далее «внедряет») эти зависимости при создании бина. Этот процесс принципиально противоположен, поэтому и назван Inversion of Control, т.к. бин сам контролирует реализацию и расположение своих зависимостей, используя прямое создание классов или такой механизм, как шаблон Service Locator.

Описание работы IoC контейнера

ApplicationContext представляет собой Spring IoC контейнер и необходим для инициализации, настройки и сборки бинов для построения приложения.

В метаданных конфигурации разработчик описывает как инициализировать, настроить IoC контейнер и собрать объекты в вашем приложении. В данном и других уроках этого цикла везде, где возможно, будет использоваться подход на основе аннотаций и Java-конфигурации. Если вы сторонник XML-конфигурации, либо хотите посмотреть как делать тоже самое через XML, обратитесь к оригинальной документации по Spring Framework или соответствующего модуля/проекта.

Настройка IoC контейнера

Как вариант, можно инициализировать контекст(ы) таким образом:

Использование @Bean аннотации

Теперь, для того, чтобы объект с типом GreetingService был доступен для использования, необходимо описать его в конфигурации следующим образом:

А для того, чтобы использовать его, достаточно выполнить следующее:

Метод getBean() может принимать в качестве аргумента как класс(как показано выше), так и названия бина(подробнее будет рассмотрено ниже), либо другие варианты, с которыми вы можете ознакомится в документации. Однако такой подход не рекомендуется использовать в production-конфигурациях, т.к. для подобных целей существует механизм Dependency Injection (DI), собственно говоря, для чего и предназначен Spring IoC контейнер. Использование DI будет рассмотрено ниже в отдельной главе.

Иногда полезно предоставить более подробное описание бина, например, в целях мониторинга. Для этого существует аннотация @Description :

Жизненный цикл бина

При совместном использовании методов, интерфейсов и аннотаций, описанных выше, учитывайте их порядок вызовов. Для методов инициализации порядок будет следующий:

Для методов разрушения порядок будет следующий:

Если вам необходимо реализовать свою собственную модель жизненного цикла бина, то в таком случае бин должен реализовывать один из интерфейсов, приведенных ниже:

После этого у вас появятся результаты работы методов при разрушении бина. Однако стоит заметить ещё раз, что это относится к обычным приложения, не относящимся к web-приложения(поскольку для них применяется отдельный тип контекста и подобный метод в них уже есть).

Области видимости(scopes) бинов

Когда вы создаете определение бинов, вы вы создаете рецепт для создания экземпляров класса, который определяет бин. Важно понять, что определение бинов является рецептом, потому что он означает, какого класса вы можете создать множество экземпляров по этому рецепту.

Использование @Configuration аннотации

Кода бин имеет зависимость от другого бина, то зависимость выражается просто как вызов метода:

В большинстве случаев, имеются такие случаи, когда бин в одной конфигурации имеет зависимость от бина в другой конфигурации. Поскольку конфигурация является источником определения бинов, то разрешить такую зависимость не является проблемой, достаточно объявить поле класса конфигурации с аннотацией @Autowired (более подробно оисано в отдельной главе):

При этом LessonsConfiguration остается без изменений:

Процесс разрешения зависимостей

IoC контейнер выполняет разрешение зависимостей бинов в следующем порядке:

Spring контейнер может разрешать зависимости между бинами через autowiring(далее, автоматическое связывание). Данный механизм основан на просмотре содержимого в ApplicationContext и имеет следующие преимущества:

Соответственно, у одной из реализации GreetingService должна быть установлена соответствующая аннотация @Qualifier :

Spring также поддерживает использование JSR-250 @Resource аннотации автоматического связывания для полей класса или параметров setter-методов:

Использование стандартных JSR-330 аннотаций

Spring Framework поддерживает JSR-330 аннотации. Эти аннотации работают таким же способом, как и Spring аннотации. Для того, чтобы работать с ними, необходимо добавить в pom.xml следующую зависимость:

Ниже приведена таблица сравнения JSR-330 и Spring аннотаций для DI:

Источник

Как именно работает Spring BeanPostProcessor?

Итак, у меня есть эта схема:

Для меня довольно ясно, что это значит:

На этапе загрузки определений компонентов выполняются следующие шаги :

В @Configuration классы обрабатываются и / или @Components проверяются на наличие и / или файлы XML обрабатываются.

Определения компонентов, добавленные в BeanFactory (каждое проиндексировано под своим идентификатором)

Затем на этапе создания bean-компонентов выполняются следующие шаги :

Каждый bean-компонент активно создается по умолчанию (создается в правильном порядке с введенными зависимостями).

После внедрения зависимости каждый компонент проходит стадию постобработки, на которой может происходить дальнейшая настройка и инициализация.

После постобработки компонент полностью инициализирован и готов к использованию (отслеживается по его идентификатору до тех пор, пока контекст не будет уничтожен)

Хорошо, для меня это довольно ясно, и я также знаю, что есть два типа постпроцессоров bean-компонентов :

Инициализаторы: инициализируйте bean-компонент, если это указано (например, @PostConstruct).

и все остальное: которые позволяют дополнительную настройку и могут выполняться до или после шага инициализации.

И выкладываю этот слайд:

Поэтому мне очень ясно, что инициализаторы bean- постпроцессоры (это методы, аннотированные аннотацией @PostContruct и автоматически вызываемые сразу после методов установки (то есть после внедрения зависимости), и я знаю, что могу использовать для выполнить некоторый пакет инициализации (как и заполнить кеш, как в предыдущем примере).

Я легко могу понять, почему мне нужен аннотированный метод @PostContruct, но я не могу представить типичный пример другого типа постпроцессора bean, не могли бы вы показать мне типичный пример того, когда они используются?

Источник

The BeanPostProcessor interface defines callback methods that you can implement to provide your own instantiation logic, dependency-resolution logic, etc. You can also implement some custom logic after the Spring container finishes instantiating, configuring, and initializing a bean by plugging in one or more BeanPostProcessor implementations.

You can configure multiple BeanPostProcessor interfaces and you can control the order in which these BeanPostProcessor interfaces execute by setting the order property provided the BeanPostProcessor implements the Ordered interface.

The BeanPostProcessors operate on bean (or object) instances, which means that the Spring IoC container instantiates a bean instance and then BeanPostProcessor interfaces do their work.

An ApplicationContext automatically detects any beans that are defined with the implementation of the BeanPostProcessor interface and registers these beans as postprocessors, to be then called appropriately by the container upon bean creation.

Example

The following examples show how to write, register, and use BeanPostProcessors in the context of an ApplicationContext.

Let us have a working Eclipse IDE in place and take the following steps to create a Spring application −

Here is the content of HelloWorld.java file −

This is a very basic example of implementing BeanPostProcessor, which prints a bean name before and after initialization of any bean. You can implement more complex logic before and after intializing a bean because you have access on bean object inside both the post processor methods.

Here is the content of InitHelloWorld.java file −

Following is the content of the MainApp.java file. Here you need to register a shutdown hook registerShutdownHook() method that is declared on the AbstractApplicationContext class. This will ensures a graceful shutdown and calls the relevant destroy methods.

Following is the configuration file Beans.xml required for init and destroy methods −

Once you are done with creating the source and bean configuration files, let us run the application. If everything is fine with your application, it will print the following message −

Источник

Spring BeanPostProcessor

In this post of Spring core, we will learn as how Spring bean post processor works. The bean post processor provides the flexibility to do some additional bean processing before and after bean initialization. The Spring bean post processor is responsible to process every bean instance available with the IoC container.

Introduction

Before we get in to the details of Spring bean post processor, let’s look at the different steps of the bean initialization and where bean post processor fit in to the picture.

Let’s see what all steps takes place during Spring Bean life cycle.

[pullquote align=”normal”]Bean post processor is helpful to validate the bean definition or can alter the bean properties based on certain requirements.[/pullquote]

1. Spring BeanPostProcessor

The BeanPostProcessor is a factory hook that allows for custom modification for the new bean. This interface defines 2 methods the implementing class should implement.

Let’s see a simple example for a better understanding:

Keep in mind that Spring IoC will pass each bean to this custom BeanPostProcessor.Also please note that this differs from the @PostConstruct annotation.The @PostConstruct is just used for the specific class we want to customize.

[pullquote align=”normal”] @PostConstruct and @PreDestroy annotations are generally considered best practice for receiving life-cycle callbacks in a modern Spring application. [/pullquote]

2 How to Register BeanPostProcessor

The easiest way to register the Spring BeanPostProcessor is by annotating the class with @Component or define the bean in bean.xml file or in the configuration file:

We can also define this in the Configuration class like:

Summary

In this class we inspect the BeanPostProcessor. We saw how Spring bean post processor works and how we can use this feature for the custom modification of new bean instances.

Источник

Подготовка к Spring Professional Certification. Часть 1: «Контейнер, IoC, бины»

Доброго времени суток, Хабр.
Сегодня я решил представить вам перевод цикла статей для подготовки к Spring Professional Certification.
Это перевод только первой статьи, если он зайдет аудитории, я продолжу выпуск переводов.

Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами (то есть между различными POJO). Таким образом, при применении DI, ваш код становится чище, проще, его становится легче понять и тестировать.
Согласно паттерну DI, создание объектов для зависимостей переходит на фабрику или отдается третьей стороне. Это означает, что мы можем сосредоточиться на использовании этих объектов вместо их создания.

В Spring Framework интерфейс org.springframework.factory.BeanFactory предоставляет фабрику для бинов, которая в то же время является IoC контейнером приложения. Управление бинами основано на конфигурации(java или xml).

Интерфейс org.springframework.context.ApplicationContext — это обертка над bean factory, предоставляющая некоторые дополнительные возможности, например AOP, транзакции, безопасность, i18n, и т.п.

Основа Spring Framework — контейнер, и наши объекты «живут» в этом контейнере.
Контейнер обычно создает множество объектов на основе их конфигураций и управляет их жизненным циклом от создания объекта до уничтожения.

Контейнер — это объект, реализующий интерфейс ApplicationContext.

Spring обеспечивает несколько разновидностей контекста.

Есть несколько основных реализаций интерфейса ApplicationContext:

Примеры создания контекста:

Если вы используете JUnit 5, то вам нужно указать 2 аннотации:

Если это не веб-приложение, то есть 2 способа:

В Spring Boot приложении:

Этот класс поместит в контейнер экземпляр класса DataSource. Позднее его можно будет использовать при доступе к базе данных.

Component scanning(сканирование компонентов) — Spring автоматически обнаруживает бины, которые будут находиться в контейнере. Это бины с аннотациями-стереотипами.

Область видимости — scope, скоуп. Существует 2 области видимости по умолчанию.

И 4 области видимости в веб-приложении.

Singleton-бины обычно создаются сразу при сканировании.
Prototype-бины обычно создаются только после запроса.

Для того чтобы использовать кастомный BFPP. Вы можете переопределить механизм получения данных из метафайлов.

Есть 3 варианта для создания таких методов:

Ниже перечислены типы DI, которые могут быть использованы в вашем приложении:

DI через конструктор считается самым лучшим способом, т.к. для него не надо использовать рефлексию, а также он не имеет недостатков DI через сеттер.
DI через поле не рекомендуется использовать, т.к. для этого применяется рефлексия, снижающая производительность.
DI через конструктор может приводить к циклическим зависимостям. Чтобы этого избежать, можно использовать ленивую инициализацию бинов или DI через сеттер.

Контейнер обрабатывает DI с помощью AutowiredAnnotationBeanPostProcessor. В связи с этим, аннотация не может быть использована ни в одном BeanFactoryPP или BeanPP.

Если внедряемый объект массив, коллекция, или map с дженериком, то Spring внедрит все бины подходящие по типу в этот массив(или другую структуру данных). В случае с map ключом будет имя бина.

Вы можете использовать разные типы внедрения:

Spring предоставляет аннотацию Qualifier, чтобы преодолеть проблему неоднозначности при DI.

Если в контейнере есть несколько бинов одного типа(SomeClass), то контейнер внедрит именно тот бин, над @Bean-методом которого стоит соответствующий квалификатор. Также можно не ставить квалификатор на метод, а использовать имя бина в качестве параметра квалификатора.
Имя бина можно можно указать через параметр аннотации Bean, а по умолчанию это имя фабричного метода.

Прокси это специальный объект, который имеет такие же публичные методы как и бин, но у которого есть дополнительная функциональность.
Два вида прокси:

Если в контейнере нет экземпляра бина, то вызывается @Bean-метод. Если экземпляр бина есть, то возвращается уже созданный бин.

В эту переменную будет внедрена строка, например из property или из view.

Как обычно, просьба присылать правки или найденные ошибки в личку.

Источник