Java Blog

Помимо ApplicationContextAware и BeanNameAware , Spring предлагает широкий спектр Aware интерфейсов обратного вызова, которые позволяют bean-компонентам указывать контейнеру, что им требуется определенная зависимость от инфраструктуры. Как правило, имя указывает тип зависимости. В следующей таблице приведены наиболее важные Aware интерфейсы: Имя Внедренная зависимость ApplicationContextAware Объявление ApplicationContext ApplicationEventPublisherAware Событие издателя вмещающего ApplicationContext BeanClassLoaderAware Загрузчик классов, используемый для загрузки классов компонентов. BeanFactoryAware Объявление BeanFactory BeanNameAware Имя объявляющего bean BootstrapContextAware Адаптер ресурсов BootstrapContext, в котором работает контейнер. Обычно доступен только в экземплярах ApplicationContext с поддержкой JCA. LoadTimeWeaverAware Определенный weaver для определения класса обработки во время загрузки. MessageSourceAware Настраиваемая стратегия д...

Когда ApplicationContext создает экземпляр объекта, который реализует интерфейс org.springframework.context.ApplicationContextAware, этому экземпляру предоставляется ссылка на этот ApplicationContext. Следующий листинг показывает определение интерфейса ApplicationContextAware: Java public interface ApplicationContextAware { void setApplicationContext(ApplicationContext applicationContext) throws BeansException; } Kotlin interface ApplicationContextAware { @Throws(BeansException::class) fun setApplicationContext(applicationContext: ApplicationContext) } Таким образом, bean-компоненты могут программно управлять созданным ими ApplicationContext через интерфейс ApplicationContext или путем приведения ссылки на известный подкласс этого интерфейса (такой как ConfigurableApplicationContext, который предоставляет дополнительные функциональные возможности). Одним из применений будет программный поиск других бинов. Иногда эта возможность полезна. Однако в целом этого...

Этот пост относится только к не веб-приложениям. В веб-реализациях Spring ApplicationContext уже есть код, который корректно завершает работу контейнера Spring IoC при завершении работы соответствующего веб-приложения. Если вы используете IoC-контейнер Spring в среде, не являющейся веб-приложением (например, в среде рабочего стола расширенного клиента), зарегистрируйте ловушку отключения в JVM. Это гарантирует плавное завершение работы и вызывает соответствующие методы уничтожения для ваших одноэлементных компонентов, чтобы освободить все ресурсы. Вы все еще должны правильно настроить и реализовать эти обратные вызовы уничтожения. Чтобы зарегистрировать обработчик завершения работы, вызовите метод registerShutdownHook(), который объявлен в интерфейсе ConfigurableApplicationContext, как показано в следующем примере: Java import org.springframework.context.ConfigurableApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; public final class...

Интерфейс Lifecycle определяет основные методы для любого объекта, который имеет свои собственные требования жизненного цикла (например, запуск и остановка некоторого фонового процесса): Java public interface Lifecycle { void start(); void stop(); boolean isRunning(); } Kotlin interface Lifecycle { fun start() fun stop() val isRunning: Boolean } Любой объект, управляемый Spring, может реализовать интерфейс Lifecycle. Затем, когда сам ApplicationContext получает сигналы запуска и остановки (например, для сценария остановки/перезапуска во время выполнения), он связывает эти вызовы со всеми реализациями жизненного цикла, определенными в этом контексте. Это делается путем делегирования LifecycleProcessor, как показано в следующем листинге: Java public interface LifecycleProcessor extends Lifecycle { void onRefresh(); void onClose(); } Kotlin interface LifecycleProcessor : Lifecycle { fun onRefresh() fun onClose() ...

Начиная с Spring 2.5 у вас есть три варианта управления поведением жизненного цикла бина: Интерфейсы обратного вызова InitializingBean и DisposableBean Пользовательские методы init() и destroy() Аннотации @PostConstruct и @PreDestroy. Вы можете комбинировать эти механизмы для управления данным бином. Если для bean-компонента настроено несколько механизмов жизненного цикла, и каждый механизм настроен с различным именем метода, то каждый настроенный метод выполняется в порядке, указанном ниже. Однако если одно и то же имя метода настроено - например, init() для метода инициализации - для более чем одного из этих механизмов жизненного цикла, этот метод выполняется один раз. Несколько механизмов жизненного цикла, настроенных для одного и того же bean-компонента с различными методами инициализации, называются следующим образом: Методы, аннотированные @PostConstruct afterPropertiesSet() как определено интерфейсом обратного вызова InitializingBean Настраиваемый метод init() Метод...

Когда вы пишете методы обратных вызовов инициализации и уничтожения, которые не используют специфичные для Spring интерфейсы обратного вызова InitializingBean и DisposableBean, вы обычно пишете методы с именами, такими как init(), initialize(), dispose() и так далее. В идеале имена таких методов обратного вызова жизненного цикла стандартизируются по всему проекту, чтобы все разработчики использовали одинаковые имена методов и обеспечивали согласованность. Вы можете настроить контейнер Spring на "поиск" именованных методов обратного вызова инициализации и уничтожения на каждом бине. Это означает, что вы, как разработчик приложения, можете написать свои классы приложения и использовать обратный вызов инициализации, называемый init(), без необходимости настраивать атрибут init-method="init" для каждого определения компонента. Контейнер Spring IoC вызывает этот метод при создании компонента (и в соответствии со стандартным контрактом обратного вызова жизненного цикла, ...

Реализация интерфейса org.springframework.beans.factory.DisposableBean позволяет бину получить обратный вызов, когда контейнер, содержащий его, уничтожен. Интерфейс DisposableBean указывает один метод: Java void destroy() throws Exception; Kotlin fun destroy() Рекомендуется не использовать интерфейс обратного вызова DisposableBean, поскольку он без необходимости связывает код со Spring. В качестве альтернативы предлагается использовать аннотацию @PreDestroy или указать общий метод, который поддерживается определениями компонентов. С метаданными конфигурации на основе XML вы можете использовать атрибут destroy-method в <bean/>. При Java конфигурации вы можете использовать атрибут destroyMethod @Bean. Рассмотрим следующее определение: <bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup"/> Java public class ExampleBean { public void cleanup() { // выполнить некоторую работу по унич...

Интерфейс org.springframework.beans.factory.InitializingBean позволяет компоненту выполнять работу по инициализации после того, как контейнер установил все необходимые свойства для компонента. Интерфейс InitializingBean определяет единственный метод: Java void afterPropertiesSet() throws Exception; Kotlin fun afterPropertiesSet() Рекомендуется не использовать интерфейс InitializingBean, потому что он без необходимости связывает код с Spring. В качестве альтернативы предлагается использовать аннотацию @PostConstruct или указать метод инициализации POJO. В случае метаданных конфигурации на основе XML вы можете использовать атрибут init-method, чтобы указать имя метода, имеющего пустую подпись без аргументов. С Java конфигурацией вы можете использовать атрибут initMethod @Bean. Рассмотрим следующий пример: <bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/> Java public class ExampleBean { public vo...

Для взаимодействия с управлением контейнером жизненного цикла компонента вы можете реализовать интерфейсы Spring InitializingBean и DisposableBean. Контейнер вызывает afterPropertiesSet() для первого и destroy() для второго, чтобы bean-компонент мог выполнять определенные действия при инициализации и уничтожении ваших bean-компонентов. Аннотации JSR-250 @PostConstruct и @PreDestroy обычно считаются лучшей практикой для получения обратных вызовов жизненного цикла в современном приложении Spring. Использование этих аннотаций означает, что ваши компоненты не связаны с интерфейсами, специфичными для Spring. Если вы не хотите использовать аннотации JSR-250, но по-прежнему хотите удалить соединение, рассмотрите метаданные определения bean-метода init и destroy-method. Внутренне Spring Framework использует реализации BeanPostProcessor для обработки любых интерфейсов обратного вызова, которые он может найти, и для вызова соответствующих методов. Если вам нужны пользовательские функции или д...