Сообщения

Показаны сообщения с ярлыком "ApplicationContext"

Spring IoC контейнер: BeanFactory или ApplicationContext

Изображение
В этом посте объясняются различия между уровнями контейнеров BeanFactory и ApplicationContext и их влияние на загрузку. Вам следует использовать ApplicationContext, если у вас нет веских причин для этого, с GenericApplicationContext и его подклассом AnnotationConfigApplicationContext в качестве общих реализаций для настраиваемой начальной загрузки. Это основные точки входа в основной контейнер Spring для всех общих целей: загрузка файлов конфигурации, запуск сканирования пути к классам, программная регистрация определений компонентов и аннотированных классов и (начиная с версии 5.0) регистрация определений функциональных компонентов. Поскольку ApplicationContext включает в себя все функциональные возможности BeanFactory, его обычно рекомендуется использовать вместо простого BeanFactory, за исключением сценариев, где необходим полный контроль над обработкой bean-компонентов. Внутри ApplicationContext (например, реализации GenericApplicationContext) несколько видов bean-компонентов обн...

Spring IoC контейнер: дополнительные возможности ApplicationContext, развертывание Spring ApplicationContext как файла RAR Java EE

Изображение
Можно развернуть Spring ApplicationContext как файл RAR, инкапсулируя контекст и все необходимые ему классы компонентов и файлы JAR библиотеки в модуле развертывания Java EE RAR. Это эквивалент начальной загрузки автономного ApplicationContext (размещенного только в среде Java EE) с возможностью доступа к серверам Java EE. Развертывание RAR является более естественной альтернативой сценарию развертывания файла WAR без заголовка - по сути, файла WAR без каких-либо точек входа HTTP, который используется только для начальной загрузки Spring ApplicationContext в среде Java EE. Развертывание RAR идеально подходит для контекстов приложений, которым не нужны точки входа HTTP, а скорее состоят только из конечных точек сообщений и запланированных заданий. Компоненты в таком контексте могут использовать ресурсы сервера приложений, такие как диспетчер транзакций JTA и связанные с JNDI экземпляры JDBC DataSource и экземпляры JMS ConnectionFactory, а также могут регистрироваться на сервере JMX пла...

Spring IoC контейнер: дополнительные возможности ApplicationContext, удобное создание экземпляра ApplicationContext для веб-приложений

Изображение
Вы можете создавать экземпляры ApplicationContext декларативно, используя, например, ContextLoader. Конечно, вы также можете создавать экземпляры ApplicationContext программно, используя одну из реализаций ApplicationContext. Вы можете зарегистрировать ApplicationContext с помощью ContextLoaderListener, как показано в следующем примере: <context-param> <param-name>contextConfigLocation</param-name> <param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value> </context-param> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> Слушатель проверяет параметр contextConfigLocation. Если параметр не существует, прослушиватель использует /WEB-INF/applicationContext.xml по умолчанию. Когда параметр действительно существует, прослушиватель разделяет строку с помощью предопределенных разделителей (запятая, точка с запятой и пробел) ...

Spring IoC контейнер: дополнительные возможности ApplicationContext, удобный доступ к низкоуровневым ресурсам

Изображение
Контекст приложения - это ResourceLoader, который можно использовать для загрузки объектов Resource. Resource - это, по сути, более функциональная версия класса JDK java.net.URL. Фактически, реализации Resource оборачивают экземпляр java.net.URL, где это необходимо. Resource может прозрачным образом получать ресурсы низкого уровня практически из любого места, включая путь к классам, расположение файловой системы, любое место, описываемое стандартным URL-адресом, и некоторые другие варианты. Если строка местоположения ресурса представляет собой простой путь без каких-либо специальных префиксов, то источник этих ресурсов является конкретным и соответствует фактическому типу контекста приложения. Вы можете настроить компонент, развернутый в контексте приложения, для реализации специального интерфейса обратного вызова, ResourceLoaderAware, который будет автоматически вызываться во время инициализации с самим контекстом приложения, переданным как ResourceLoader. Вы также можете предоставит...

Spring IoC контейнер: дополнительные возможности ApplicationContext, асинхронные слушатели, упорядочивание слушателей

Изображение
Асинхронные слушатели Если вы хотите, чтобы конкретный слушатель обрабатывал события асинхронно, вы можете повторно использовать обычную поддержку @Async. В следующем примере показано, как это сделать: Java @EventListener @Async public void processBlockedListEvent(BlockedListEvent event) { // BlockedListEvent обрабатывается в отдельном потоке } Kotlin @EventListener @Async fun processBlockedListEvent(event: BlockedListEvent) { // BlockedListEvent обрабатывается в отдельном потоке } Помните о следующих ограничениях при использовании асинхронных событий: Если асинхронный прослушиватель событий выдает исключение, оно не передается вызывающей стороне. Методы асинхронного прослушивателя событий не могут публиковать последующее событие, возвращая значение. Если вам нужно опубликовать другое событие в результате обработки, введите ApplicationEventPublisher, чтобы опубликовать событие вручную. Упорядочивание слушателей Если вам нужно, чтобы один слушатель вызывалс...

Spring IoC контейнер: дополнительные возможности ApplicationContext, слушатели событий на основе аннотаций

Изображение
Начиная с Spring 4.2, вы можете зарегистрировать прослушиватель событий для любого общедоступного метода управляемого bean-компонента с помощью аннотации @EventListener. BlockedListNotifier можно переписать следующим образом: Java public class BlockedListNotifier { private String notificationAddress; public void setNotificationAddress(String notificationAddress) { this.notificationAddress = notificationAddress; } @EventListener public void processBlockedListEvent(BlockedListEvent event) { // уведомляем соответствующие стороны через notificationAddress... } } Kotlin class BlockedListNotifier { lateinit var notificationAddress: String @EventListener fun processBlockedListEvent(event: BlockedListEvent) { // уведомляем соответствующие стороны через notificationAddress... } } Сигнатура метода еще раз объявляет тип события, которое он слушает, но на этот раз с гибким именем и без реализации определенного инте...

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

Изображение
Обработка событий в ApplicationContext обеспечивается через класс ApplicationEvent и интерфейс ApplicationListener. Если bean-компонент, реализующий интерфейс ApplicationListener, развертывается в контексте, каждый раз, когда ApplicationEvent публикуется в ApplicationContext, этот bean-компонент получает уведомление. По сути, это стандартный шаблон проектирования Observer. Начиная с Spring 4.2, инфраструктура событий была значительно улучшена и предлагает модель на основе аннотаций, а также возможность публиковать любое произвольное событие (то есть объект, который не обязательно является наследником ApplicationEvent). Когда такой объект публикуется, Spring упаковывает его в событие для вас. Ниже описаны стандартные события, которые предоставляет Spring: ContextRefreshedEvent Публикуется при инициализации или обновлении ApplicationContext (например, с помощью метода refresh() в интерфейсе ConfigurableApplicationContext). Здесь "инициализировано" означает, что все bean-ком...

Spring IoC контейнер: дополнительные возможности ApplicationContext, интернационализация с использованием MessageSource

Изображение
Интерфейс ApplicationContext расширяет интерфейс под названием MessageSource и, следовательно, обеспечивает функциональность интернационализации (“i18n”). Spring также предоставляет интерфейс HierarchicalMessageSource, который может разрешать сообщения иерархически. Вместе эти интерфейсы обеспечивают основу, на которой Spring влияет на разрешение сообщений. Методы, определенные в этих интерфейсах, включают: String getMessage(String code, Object[] args, String default, Locale loc): основной метод, используемый для получения сообщения из MessageSource. Если сообщение для указанной локали не найдено, используется сообщение по умолчанию. Любые переданные аргументы становятся значениями замены с использованием функции MessageFormat, предоставляемой стандартной библиотекой. String getMessage(String code, Object[] args, Locale loc): по сути то же самое, что и предыдущий метод, но с одним отличием: нельзя указать сообщение по умолчанию. Если сообщение не может быть найдено, создается исключ...

Spring IoC контейнер: дополнительные возможности ApplicationContext

Изображение
Пакет org.springframework.beans.factory предоставляет базовые функции для управления и манипулирования bean-компонентами, в том числе программным способом. Пакет org.springframework.context добавляет интерфейс ApplicationContext, который расширяет интерфейс BeanFactory, в дополнение к расширению других интерфейсов для обеспечения дополнительных функций в фреймворк-ориентированном стиле. Многие люди используют ApplicationContext полностью декларативно, даже не создавая его программно, а вместо этого полагаясь на вспомогательные классы, такие как ContextLoader, для автоматического создания экземпляра ApplicationContext в рамках обычного процесса запуска веб-приложения Java EE. Чтобы улучшить функциональность BeanFactory в более ориентированном на фреймворк стиле, пакет context также предоставляет следующие функции: Доступ к сообщениям в стиле i18n через интерфейс MessageSource. Доступ к ресурсам, таким как URL-адреса и файлы, через интерфейс ResourceLoader. Публикация событий, а име...