В этой статье в основном суммируются некоторые методы обратного вызова и расширяемые точки, предоставленные контейнером Spring до и после инициализации экземпляра. Используя эти методы и точки расширения, некоторая специальная логическая обработка может быть выполнена до и после экземпляров инициализации пружины.
В основном представлено следующее:
Настройка обратного цикла жизненного цикла на уровне класса настройка, инициализируемое интерфейс и аннотация постконструкции
Интерфейс BeanpostProcessor ура
1. Обратный вызов жизненного цикла на уровне класса
1.1INIT-Метод
Ссылка: Springbeanxsdinit-Method
init-method-это элемент конфигурации при объявлении боба в файле конфигурации пружины. Значение элемента конфигурации init-method-это метод без параметра в классе, но может быть брошено исключение. Этот метод будет вызван после того, как пружинный контейнер создает объект и устанавливает значение свойства.
Функции, которые могут быть реализованы с помощью init-method, согласуются с интерфейсом инициализируемой и аннотацией постконтронта
Файлы конфигурации пружины и тестовые классы следующие:
<bean id = "initmethodbeanservice" init-method = "init"> <name = "f2" value = "2"/> </bean>
Тестовый класс выглядит следующим образом:
открытый класс initmethodbeanservice {private static integer f1; private integer f2; static {f1 = 1; System.out.println ("initmethodbeanservice static block execute ...");} public initmethodbeanservice () {system.out.println ("initmethodbeanservice execute ... init () {system.out.println ("initmethodbeanservice Метод init execute ...");} public integer getf2 () {return f2;} public void setf2 (Integer f2) {this.f2 = f2; system.out.println ("initmethodbeanser setf2 method ...");Результаты выполнения напечатаны следующим образом:
Initmethodbeanservice static block Выполнение ... initmethodbeanservice Constructe Метод выполнения ... initmethodbeanservice setf2 Метод execute ... initmethodbeanservice Метод init execute ... Метод тестирования выполнить ...
1.2Initializebebean интерфейс
Ссылка: Весенний официальный документ бобов Factory-Lifecyclecycle initializationBean
Интерфейс инициализируется интерфейс, который объявляет метод Afterpropertiesset, который вызывается после того, как пружинный контейнер создает объект и устанавливает значение свойства. Это согласуется с функциональностью, реализованной выше инициатором, не рекомендует использовать интерфейс инициализируемой бухты.
Пример относительно прост, а не в списке
1.3постконизм аннотации
Перевод: Весенние официальные документы бобов-пост-конструкция и предпринимательские аннотации
@Postconstruct Annotation-это метод обратного вызовов жизненного цикла, который согласуется с реализацией инициализации интерфейсов.
@Postconstructpublic void postconstruct () {System.out.println ("PostConstructRevice PostConstruct Method Execute ...");}Суммируйте три вышеупомянутые методы обратного вызова
1. Все созданы экземпляры и пост обработки для отдельных классов
2. Время выполнения называется после того, как вводится инстанция класса, и переменные -члены вводится.
3. Для init-method вы также можете настроить метод инициализации по умолчанию под элементом бобов файла конфигурации пружины, а элемент конфигурации по умолчанию-method
4. Если методы инициализации, настроенные в трех вышеуказанных методах, различаются, порядок выполнения: @postconstruct Метод аннотации> Метод инициализации Bean's Afterpropertiesset> init-method; Если методы, настроенные в трех методах, одинаковы, метод будет выполняться только один раз (см.: Spring Office Document Beans-Factory-Lifecycl-Compled-эффект)
5. Существует первоначальный метод обратного вызова, и есть также уничтоженный метод обратного вызова. @PostConstruct Метод аннотации> Методы инициализации Bean's AwpredPropertiesset> init-method соответствуют методу аннотации @predestroy> EndayableBean's Dressent> Dressust Method Method
2. Расширение уровня контейнера
Перевод: Весенний официальный документ 3.8 ContainerextensionPoints
Вообще говоря, разработчикам не нужно настраивать подкласс ApplicationContext для расширения контейнеров Springioc. Контейнеры Springioc могут достичь расширения контейнеров Springioc через некоторые открытые интерфейсы.
2.1BeanpostProcessor Interface
2.1.1 Инициализация экземпляра постпроцессора и постпроцессорной цепи
Интерфейс BeanpostProcessor определяет два метода обратного вызова контейнера послепроцессесбегинициализации и постпроцессафтеринициализации, которые используются для некоторой логической обработки после инициализации экземпляра и будут обрабатываются для всех экземпляров в контейнере. Класс, который реализует интерфейс BeanpostProcessor, называется постпроцессором экземпляра Бин.
Если постпроцессоры с несколькими постпроцессорами интегрированы в контейнеры Springioc, набор этих постпроцессоров называется инициализацией экземпляра фасоля постпроцессорной цепочки.
Метод PostprocessBefeInitialization выполняется после завершения экземпляра класса, а впрыск переменной членов завершена, и перед методом инициализации (например, метод инициализации Bean's Afterpropertiesset)
Метод постопроцессафтеринициализации выполняется после того, как экстремация класса и заполнение переменной -члена завершается, и метод инициализации (например, метод инициализации Bean's Afterpropertiesset) выполняется после
Суммировать:
1. Постпроцессор инициализации экземпляра в основном используется для некоторых прокси-операций на экземпляре. Некоторые функции, которые используют AOP весной, также реализованы через пост-обработки.
2. Инициализация экземпляра постопроцессорной цепочки представляет собой несколько постпроцессоров, и будут проблемы с порядком выполнения. Вы можете реализовать упорядоченный интерфейс, чтобы указать порядок выполнения пост-обработки. Заказанный интерфейс объявляет метод getorder. Чем меньше возвращаемое значение метода, тем выше приоритет пост-обработки и более раннее выполнение.
3. При инициализации постпроцессора путем реализации интерфейса BeanpostProcessor рекомендуется реализовать упорядоченный интерфейс и указать приоритет.
4. Объем этих постпроцессоров - текущий контейнер Springioc, то есть контейнер Springioc, который объявляется постпроцессором. Для контейнеров Springioc с иерархическими структурами инициализация цепочки процессора после экземпляра не действует на экземпляре, инициализированном другими контейнерами, даже если два контейнера находятся на одной иерархии.
5. Класс реализации инициализации экземпляра постпроцессора должен быть объявлен таким же, как обычные бобы, управляемые пружиной. Контейнер Springioc автоматически обнаружит его и добавит его к инициализации экземпляра постопроцессорной цепи.
6. По сравнению с автоматическим обнаружением, мы также можем вызвать метод AddBeanpostProcessor, настраиваемый beanfactory для программного добавления инициализации экземпляра постпроцессора в цепочку постпроцессорной инициализации экземпляра. Это более практично в сценариях, где необходимо определить условия добавления. Этот подход программирования игнорирует порядок, указанный в реализованном упорядоченном интерфейсе, но будет действовать во всех случаях, которые автоматически обнаруживаются до инициализации постпроцессора.
2.1.2 Инициализация экземпляра бобов постпроцессор и AOP
Beanpostprocessor-это специальный интерфейс, и класс, реализующий этот интерфейс, будет использоваться в качестве постпроцессора для экземпляров бобов, управляемых весной. Таким образом, на специальном этапе запуска контекста приложения весеннего приложения все экземпляры, которые реализуют интерфейс BeanpostProcessor, будут непосредственно инициализированы, и классы, на которые ссылается экземпляр, также будут созданы экземпляры. Затем как постпроцессор, чтобы применить другие нормальные экземпляры.
Поскольку автоматический прокси AOP реализован в форме создания постпроцессоров, ни экземпляр боба, ни экземпляр боба не инициализирует экземпляр постпроцессорной цепи или его ссылочный экземпляр. Следовательно, не плести по лицу на этих примерах. (Для этих случаев будет сгенерировано сообщение журнала: «Класс Foo не может быть обработан всеми созданиями постпроцессорных цепей, то есть не может быть автоматически проксирован»).
Примечание. Когда постпроцессор экстремения относится к другим бобам в форме автоматического использования или @Resource, контейнер пружины может вводить некацированные бобы, когда ему вводятся зависимость сопоставления типов (например, класс реализации послепроцессорного постопроцессора зависит от фасоли. вводить в форме соответствия типа, и в это время может быть введен неспособный боб). Это также может привести к проведению автоматического обеспечения или других методов экземпляра постпроцессорной обработки.
2.1.3 Инициализация экземпляра боба постпроцессорной пример
Открытый класс BeanpostProcessorService реализует BeanpostProcessor {@Override publocessAfterinitialization (Object O, String S) Throws Beansexception {System.out.println («Beanpostprocesserservice postprocessafterinitialization execute ...»; S) Throws Beansexception {System.out.println ("Beanpostprocessorservice postprocessbebessbeforeinialization Метод выполнения ..."); return o;}}2.2BeanFactoryPostProcessor Interface
2.2.1 Beanfactory Postprocessor
Реализуя интерфейс BeanFactoryPostProcessor, вы можете прочитать метаданные конфигурации бобов, управляемые контейнером, и внести изменения до создания бобов. Эти бобы называются постпроцессорами BeanFactory.
Сходства и различия между BeanFactoryPostProcessors и BeanpostProcessor Interfaces:
Сходство:
Все это постпроцессоры на уровне контейнеров
Все можно настроить с несколькими постпроцессорами, и порядок выполнения указан путем реализации упорядоченного интерфейса.
Они обрабатываются для бобов, управляемых в контейнерах, объявленных интерфейсами. В контейнерах с иерархическими структурами бобы в других контейнерах не могут быть обработаны, даже если два контейнера находятся на одном уровне.
Все они должны быть объявлены только в контейнере, как обычные бобы. Контейнер автоматически обнаружит и зарегистрируется как постпроцессор.
Конфигурация свойства инициализации задержки будет проигнорирована
Различия:
Интерфейс BeanFactoryPostProcessors обрабатывает метаданные конфигурации бобов перед экстремацией бобов, а интерфейс BeanpostProcessor обрабатывает экземпляр бобов после экземпляра бобов **
Интерфейс BeanFactoryPostProcessors также может получить экземпляр боба через метод BeanFactory.getBean (), который приведет к созданию экземпляра боба. Поскольку постпроцессор BeanFactoryPostProcessors выполняется до того, как все бобы будут созданы, метод BeanFactory.getBean () приведет к заранее, что бобы будут создавать, что нарушает жизненный цикл стандарта контейнера, что может вызвать некоторые негативные воздействия (например, фасоль, созданный заранее, будет игнорировать обработку навыкающегося постанированного поста).
2.2.2 Встроенный и пользовательский постпроцессор Beanfactory Beanfactory
Spring имеет встроенные постпроцессоры Beanfactory (например: Propertyplaceholderconfigurer и PropertyoverrideConfigurer). Он также поддерживает реализацию интерфейса BeanFactoryPostProcessor и настраивает постпроцессор BeanFactory. Давайте поговорим о встроенных постпроцессорах Spring и пользовательских постпроцессорах.
Propertyplaceholderconfigurer
Чтобы избежать рисков, вызванных изменением основного файла определения XML, Spring обеспечивает разделение конфигурации и может настроить некоторые переменные, которые могут быть изменены в файл конфигурации свойства и ссылаться на его в файле определения XML в качестве заполнителя. Таким образом, изменение конфигурации требует только изменения файла конфигурации атрибута. PropertyPlaceholderConfigurer используется для обнаружения заполнителей и замены заполнителей на значения свойств конфигурации. Примеры следующие:
PropertyPlaceholderConfigurer использует файл конфигурации свойства JDBC.Properties для замены заполнителя свойства для информации, связанной с базой данных, в компоненте DataSource с соответствующим значением конфигурации во время выполнения.
Конфигурация XML выглядит следующим образом:
<Bean> <name = name = "locations" value = "classpath: com/foo/jdbc.properties"/> </bean> <bean id = "dataSource" destry-method = "close"> <property name = "DriverClassname" value = "$ {jdbc.driverclassname}"/> <Property name = "value = value = value =" jdbc.rc. <name = "username" value = "$ {jdbc.username}"/> <name = "password" value = "$ {jdbc.password}"/>Файл конфигурации атрибута jdbc.properties заключается в следующем:
jdbc.driverclassname = org.hsqldb.jdbcdriverjdbc.url = jdbc: hsqldb: hsql: // Производство: 9002jdbc.username = sajdbc.password = root
PropertyPlaceholderCurefurer не только поддерживает чтение файлов конфигурации свойств, но и поддерживает чтение свойств системы. Приоритет чтения может быть настроен через значение свойства SystemPropertiesMode. Различные значения описаны следующим образом:
0: не читайте свойства системы
1: Если конфигурация для соответствующего заполнителя не получена в файле конфигурации атрибута, атрибут системы считывается. По умолчанию 1
2: Сначала прочитайте атрибуты системы, а затем прочитайте ссылочный файл конфигурации атрибута. Эта конфигурация может привести к тому, что свойства системы перезаписывают файл конфигурации.
PropertyoverRideConfigurer
Класс PropertyOverrideConfigurer может напрямую назначать значения бобам в контейнере, ссылаясь на файл конфигурации свойства. Когда свойство боба назначается несколькими экземплярами класса PropertyOverRideConfigurer, последнее значение переопределяет предыдущее.
Присвоение приведенного выше посуды из DataSource в качестве примера:
В классе PropertyOverrideConfigurer используется новый способ ссылаться на файл конфигурации свойства, следующим образом:
<Контекст: Property-Override location = "classpath: override.properties"/>
Правила именования свойств переопределения. Файл конфигурации свойств отличается от правил вышеуказанного (в приведенном выше примере необходимо убедиться, что имя свойства и заполнитель являются последовательными), а правила именования - Beanname.property.
dataSource.driverClassname = com.mysql.jdbc.driverdatasource.url = jdbc: mysql: mydbdatasource.username = sadatasource.password = root
Поддерживает назначение составных атрибутов, но гарантирует, что объект, который ссылается на назначенный атрибут, не является пустым, например: foo.fred.bob.sammy = 123
Постпроцессор фабрики на заказ
Постпроцессор фабрики на заказ внедряет интерфейс BeanFactoryPostPostProcessor, чтобы завершить модификацию метаданных конфигурации бобов, управляемых пружинным контейнером. Например: измените значение, введенное атрибутами класса, пример заключается в следующем:
Определите пользовательский пользовательский сборник
открытый класс userbean {private String username; public String getUsername () {return username;} public void setusername (string username) {this.username = username;}}Файл конфигурации Spring XML настраивает класс пользователя и внедряет значение хаха в атрибут имени пользователя имени пользователя
<bean/> <bean id = "user"> <name = "username" value = "хаха"/> </bean>
Ниже приведен постпроцессор фабрики фабрики, измените значение имени пользователя собственности на Heihei
public class BeanFactoryPostProcessorService implements BeanFactoryPostProcessor { @Override public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException { System.out.println("BeanFactoryPostProcessorService postProcessBeanFactory method execute..."); Beandefinition bd = beanfactory.getbeandefinition («Пользователь»); MitablePropertyValues pv = bd.getPropertyValues (); if (pv.contains ("username")) {pv.addpropertyvalue ("имя пользователя", "heihei"); }}}Суммировать
Выше приведено подробное объяснение обратных вызовов пружинного цикла и расширений контейнеров в этой статье. Я надеюсь, что это будет полезно для всех. Заинтересованные друзья могут продолжать ссылаться на этот сайт:
Краткое обсуждение применения пользовательских аннотаций весной
Анализ кода IOC весны
Пример использования Springmvc interceptor
Если есть какие -либо недостатки, пожалуйста, оставьте сообщение, чтобы указать это. Спасибо, друзья, за вашу поддержку на этом сайте!