Для чего существует такое количество applicationcontext spring
Spring ApplicationContext
Узнайте об интерфейсе ApplicationContext в Spring и о том, как настроить компоненты в некоторых наиболее распространенных типах ApplicationContext.
1. Обзор
2. Интерфейс ApplicationContext
Одной из основных особенностей пружинного каркаса является контейнер IoC (Инверсия управления). Контейнер Spring IoC отвечает за управление объектами приложения. Он использует инъекцию зависимостей для достижения инверсии управления.
3. Что такое Весенняя Фасоль?
Итак, должны ли мы настроить все объекты нашего приложения как Spring beans? Ну, как лучшая практика, мы не должны этого делать.
Кроме того, как правило, мы не должны настраивать мелкозернистые объекты домена в контейнере. Обычно ответственность за создание и загрузку объектов домена лежит на DAO и бизнес-логике.
Итак, давайте определим простой класс Java, который мы будем использовать в качестве компонента Spring в этом уроке:
4. Настройка бобов в контейнере
Как мы знаем, основная задача ApplicationContext заключается в управлении бобами.
4.1. Конфигурация на основе Java
Во-первых, мы начнем с конфигурации на основе Java, поскольку это самый новый и наиболее предпочтительный способ настройки компонентов. Он доступен с весны 3.0 и далее.
Конфигурация Java обычно использует @Bean -аннотированные методы в классе @Configuration . Аннотация @Bean в методе указывает, что метод создает пружинный компонент. Кроме того, класс с аннотацией @Configuration указывает, что он содержит конфигурации компонентов Spring.
Итак, давайте теперь создадим класс конфигурации, чтобы определить наш Account Service класс как Spring bean:
4.2. Конфигурация на основе аннотаций
Spring 2.5 представила конфигурацию на основе аннотаций в качестве первого шага для включения конфигураций компонентов в Java.
Примечательно, что мы также используем эти аннотации с конфигурацией на основе Java. Кроме того, Spring продолжает добавлять новые возможности к этим аннотациям с каждым выпуском.
Итак, теперь давайте рассмотрим простой пример этой конфигурации.
Во-вторых, мы создадим класс User Service и определим его как Spring bean, используя аннотацию @Component :
А затем мы напишем простой тестовый случай для проверки этой конфигурации:
4.3. Конфигурация на основе XML
Наконец, давайте рассмотрим конфигурацию на основе XML. Это традиционный способ настройки бобов весной.
5. Типы ApplicationContext
5.1. Аннотацияconfigapplicationcontext
Итак, давайте рассмотрим простой пример использования контейнера AnnotationConfigApplicationContext с нашей конфигурацией на основе Java:
5.2. аннотацияconfigwebapplicationcontext
Мы можем использовать этот класс при настройке прослушивателя Spring ContextLoaderListener servlet или Spring MVC DispatcherServlet в web.xml файл.
Кроме того, начиная с Spring 3.0 и далее, мы также можем программно настроить этот контейнер контекста приложения. Все, что нам нужно сделать, это реализовать интерфейс WebApplicationInitializer :
5.3. XmlWebApplicationContext
5.4. Файловая система xmlapplicationcontext
Например, давайте посмотрим, как мы можем создать этот контейнер Spring и загрузить компоненты для нашей конфигурации на основе XML:
5.5. ClassPathXmlApplicationContext
Итак, давайте рассмотрим пример использования этого класса:
6. Дополнительные возможности ApplicationContext
6.1. Разрешение сообщений
Мы можем использовать StaticMessageSource для программного добавления сообщений в источник. Однако он поддерживает базовую интернационализацию и больше подходит для тестов, чем для производственного использования.
Теперь давайте посмотрим, как мы можем использовать Источник сообщений для чтения сообщений из файла свойств.
Сначала мы создадим файл messages.properties в пути к классу:
Во-вторых, мы добавим определение компонента в наш класс Account Config :
В-третьих, мы введем MessageSource в службу учетных записей :
Наконец, мы можем использовать метод GetMessage в любом месте службы Account для чтения сообщения:
6.2. Обработка событий
7. Заключение
Java Spring несколько ApplicationContext
определение весны ApplicationContext очень неоднозначно, я почти закончил целую книгу учебника, но все еще не могу понять, что такое ApplicationContext стенд для.
Центральный интерфейс для настройки для приложения. Это доступно только для чтения во время работы приложения, но может быть перезагружено, если реализация поддерживает это.
в корневой интерфейс для доступа к контейнеру Spring bean. Это основное представление клиента контейнера bean.
сверху, мои вопросы:
1) я продолжаю видеть книгу, упомянутую «контейнер», на что ссылается контейнер? Один контейнер означает ли это один процесс java? или один контейнер относится к одному
6 ответов
контейнером они ссылаются на весну ядра инверсия контейнера управления. Контейнер предоставляет способ инициализации / начальной загрузки приложения (загрузка конфигурации в xml-файлы или аннотации) с помощью отражение, и управлять жизненным циклом объектов Java, которые называются фасоль или управляемые объекты.
На этом начальном этапе у вас нет (обычно, но это возможно) управления в ваше приложение вместо этого вы получите полностью инициализированное состояние для приложения, когда загрузка будет выполнена (или ничего, в случае сбоя).
это замена или, возможно, дополнение к тому, что называется контейнер EJB3, но весны не придерживаться EJB с определенными стандартом. Исторически, принятие EJB было ограничено сложностью этой спецификации, с весной, являющейся недавно созданным проектом для ejb3 сопоставимые функции, работающие на jvm J2SE и без контейнера EJB, и с гораздо более простой конфигурацией.
по вашему второй вопрос: у вас может быть несколько экземпляров ApplicationContexts, в этом случае они будут полностью изолированы, каждый со своей конфигурацией.
1) я продолжаю видеть книгу, упомянутую «контейнер», на что ссылается контейнер? Один контейнер означает ли это один процесс java? или один контейнер ссылается на один объект ApplicationContext?
2) Если я создаю два экземпляра ApplicationContext в одном приложении java (один основной корпус), являются ли эти два интерфейса одним центральным контейнером? Или два отдельных разных экземпляра? См. код ниже, в чем разница между context1 и context2? Если есть синглтон в бобах.xml, он вызывается context1 и context2, они разделены экземпляр или тот же экземпляр?
ApplicationContext context1 = новый ClassPathXmlApplicationContext («Beans.XML»); ApplicationContext context2 = новый ClassPathXmlApplicationContext («Beans.xml»);>
С этим instanciations, вы получите 2 совершенно независимых контекстов применения. Один боб, объявленный первым, не будет найден в другом.
обычно имеет более одного контекста приложения в веб-приложении, т. к. пружина имеет понятие hierachies из ApplicationContext. Вы можете объявить их как:
это используется в Spring MVC, где у вас обычно есть один корневой контекст (для всех бобов не имеет прямого отношения к MVC DispatcherServlet ) и один дочерний контекст, посвященный DispatcherServlet который будет содержать компоненты для контроллеров, представлений, перехватчиков и т. д.
Я продолжаю видеть книгу, упомянутую «контейнер», что такое контейнер обратиться? Один контейнер означает ли это один процесс java? или один контейнер относится к одному объекту ApplicationContext?
здесь контейнер означает контейнер spring, который является не чем иным, как ApplicationContext. Это внутренне считывает конфигурацию spring и загружает классы на основе конфигурации. Вы можете подумать, что это SpringProcessor, который предоставляет различные функции, такие как bean инициализация, инъекция, i18n, обработка бобов и т. д. с полки
ApplicationContext context1 = новый ClassPathXmlApplicationContext («Beans.xml»); ApplicationContext context2 = новый ClassPathXmlApplicationContext («Beans.xml»);
1) контейнер-это объект Java, экземпляр одной из реализаций ApplicationContext, таких как ClassPathXmlApplicationContext.
2)это 2 разных контейнера, если фасоль.xml имеет одноэлементный компонент B1, затем context1.getBean («B1») и context2.getBean («B1») вернет 2 разных экземпляра B1
ApplicationContext-это реализация контейнера Spring. Проще говоря, Spring container управляет всем приложением Spring через ApplicationContext. Контейнер весны через ApplicationContext управляет жизненным циклом фасоли весны i; e от инициирования к разрушению.
контейнер spring вложен внутри контейнера J2EE.
Я продолжаю видеть книгу, упомянутую «контейнер», что такое контейнер обратиться? Один контейнер означает один процесс java? или один контейнер относится к одному объекту ApplicationContext?
контейнер управляет жизненным циклом объекта. Tomcat является примером контейнера. Так же, как Spring container управляет приложением через ApplicationContext, контейнер J2EE Tomcat управляет приложением через интернет.в XML
контейнер обеспечивает поддержку коммуникаций. Безопасность в веб-приложении. Поддержка JSP, интернационализация, распространение событий и многие другие функции. Он поддерживает многопоточность создает новый поток для каждого запроса ресурса. Вам не нужно явно писать код для этого. Как и контейнер spring, контейнер J2ee управляет жизненным циклом сервлета.
Если я создаю два экземпляра ApplicationContext в одном приложении java (один Основной корпус), эти два интерфейса к одному центральному контейнеру?
вы добавили тег «java-ee». Весной часто используется в веб-приложениях, работающих на сервере приложений. Как правило, каждое веб-приложение будет иметь свое собственное приложение. Веб-приложения разделены и, вероятно, это то, что называется контейнером в документации, поскольку вы не можете регулярно обмениваться переменными с различными приложениями / контейнерами.
вы можете иметь два контекста в приложении. Если у вас есть два контекста, каждый будет иметь свой собственный синглтон.
Spring: в поисках контекста
Пару месяцев назад в моем профиле был опубликован подробный пост по загрузке классов на JVM. После этого доклада мои коллеги задались хорошим вопросом: а какой механизм использует Spring для разбора конфигураций и как он загружает классы из контекста?
После многих часов дебага спринговых исходников мой коллега экспериментальным путём докопался до той самой простой и понятной правды.
Немного теории
Сразу определим, что ApplicationContext — это главный интерфейс в Spring-приложении, который предоставляет информацию о конфигурации приложения.
Перед тем, как перейти непосредственно к демонстрации, взглянем на этапы формирования ApplicationContext:
В этом посте разберем первый этап, так как нас интересует именно чтение конфигураций и создание BeanDefinition.
BeanDefinition — это интерфейс, который описывает бин, его свойства, аргументы конструктора и другую метаинформацию.
Что касается конфигурации самих бинов, у Spring есть 4 способа конфигурации:
Xml конфигурация
За основу берем простой проект:
Здесь следует немного пояснить, какие методы и для чего используются:
В 25 строке идет объявление и инициализация ApplicationContext через конфигурацию Xml.
Конфигурационный Xml-файл выглядит следующим образом:
При конфигурации бина указываем реально существующий class. Обратите внимание на заданное свойство lazy-init=”true”: в этом случае бин будет создаваться только после запроса его из контекста.
Смотрим, как Spring при поднятии контекста разрулит ситуацию с классами, объявленными в конфигурационном файле:
Разберемся с деталями Xml конфигурации:
— Чтением файла конфигурации занимается класс XmlBeanDefinitionReader, который реализует интерфейс BeanDefinitionReader;
— XmlBeanDefinitionReader на входе получает InputStream и загружает Document через DefaultDocumentLoader:
— После этого каждый элемент этого документа обрабатывается и, если он является бином, создается BeanDefinition на основе заполненных данных (id, name, class, alias, init- method, destroy-method и др.):
— Каждый BeanDefinition помещается в Map, который хранится в классе DefaultListableBeanFactory:
В коде Map выглядит следующим образом:
Теперь в том же конфигурационном файле добавим еще одно объявление бина с классом film.BadVillain:
Смотрим, что получится, если распечатать список созданных BeanDefenitionNames и загруженные классы:
Несмотря на то, что класса film.BadVillain, указанного в конфигурационном файле, не существует, Spring отрабатывает без ошибок:
Cписок BeanDefenitionNames содержит 2 элемента; то есть, те 2
BeanDefinition, сконфигурированные в нашем файле, были созданы.
Конфигурации обоих бинов, по сути, одинаковы. Но, при этом существующий класс загрузился, никаких проблем не возникло. Из чего можно сделать вывод, что попытка загрузить несуществующий класс также была, но провальная попытка ничего не сломала.
Попытаемся получить еще и сами бины по их именам:
Если в первом случае был получен валидный бин, то во втором случае прилетел exception.
Обратите внимание на stack trace: сработала отложенная загрузка классов. Выполняется обход всех загрузчиков классов в попытке найти искомый класс среди загруженных ранее. И после того, как нужный класс не был найден, с помощью вызова метода Utils.forName, происходит попытка найти несуществующий класс по имени, что привело к получению закономерной ошибки.
При поднятии контекста загрузился только один класс, при этом попытка загрузки несуществующего файла не привела к ошибке. Почему так произошло?
Всё потому, что мы прописали lazy-init:true и запретили Spring создавать экземпляр бина, где и генерируется полученный ранее exception. Если убрать это свойство из конфигурации либо изменить его значение lazy-init:false, то описанная выше ошибка также вылетит, но не будет проигнорирована и приложение остановиться. В нашем случае контекст был проинициализирован, но мы не смогли создать экземпляр бина, т.к. указанный класс не был найден.
Groovy конфигурация
При конфигурации контекста с помощью Groovy-файла, необходимо сформировать GenericGroovyApplicationContext, который принимает на вход строку с конфигурацией контекста. Чтением контекста в данном случае занимается класс GroovyBeanDefinitionReader. Эта конфигурация работает по сути так же, как и Xml, только с Groovy-файлами. К тому же, GroovyApplicationContext нормально работает и с Xml-файлом.
Пример простого конфигурационного Groovy-файла:
Пробуем проделать то же самое, что и с Xml:
Ошибка вылетает сразу: Groovy так же, как и Xml, создает BeanDefenition’ы, но в данном случае постпроцессор сразу выдаёт ошибку.
Конфигурация через аннотации с указанием пакета для сканирования или JavaConfig
Данная конфигурация отличается от двух предыдущих. В конфигурация через аннотации используется 2 варианта: JavaConfig и аннотация над классами.
Здесь используется один и тот же контекст: AnnotationConfigApplicationContext(“package”/JavaConfig.class). Работает он в зависимости от того, что было передано в конструктор.
В контексте AnnotationConfigApplicationContext есть 2 приватных поля:
Создаем конфигурационный файл с максимально простым бином. Смотрим, что загрузится:
Если в случае с Xml и Groovy загрузилось столько BeanDefinition, сколько было объявлено, то в данном случае в процессе поднятия контекста загружаются как объявленные, так и дополнительные BeanDefinition. В случае реализации через JavaConfig все классы загружаются сразу, в том числе и класс самого JavaConfig, так как он сам является бином.
Еще один момент: в случае с Xml и Groovy конфигурациями загрузилось 343 файла, здесь же произошла более “тяжелая” загрузка количеством 631 доп файл.
Этапы работы ClassPathBeanDefinitionScanner:
Рассмотрим работу сканера на простом примере.
Создаем собственную аннотацию для поиска соответствующих классов:
Создаем 2 класса: один со стандартной аннотацией Component, второй — с кастомной аннотацией:
В результате получаем сформированные BeanDefinition для этих классов и успешно загруженные классы.
Вывод
Из всего вышесказанного на поставленные вопросы можно ответить следующим образом:
Что такое контекст Spring и как его создать?
Контекст (а у него есть даже интерфейс — org.springframework.context.ApplicationContext ) — это некоторое окружение, в котором работает приложение на Spring Framework. Страшные аббревиатуры DI, IoC — это всё про него. Собственно, контекст создаёт и хранит экземпляры классов вашего приложения, определяет их зависимости друг с другом и автоматически их задаёт.
Безусловно, для того чтобы Spring создал контекст с экземплярами классов, ему нужно предоставить дополнительную информацию — мета-данные, из каких классов/объектов состоит ваше приложение, как они создаются, какие у них есть зависимости и т. д.
Итого: Spring Context + мета-данные = работающее приложение.
Где найти контекст?
Контекст является ключевой функциональностью Spring и лежит в maven-зависимости spring-context (на момент написания — org.springframework:spring-context:5.1.4.RELEASE ). Обычно эта зависимость является транзитивной для остальных проектов Spring. И если вы, например, подключаете spring-boot-starter, то она подключится автоматически, и не нужно думать про то, где её взять.
Но если вы хотите попробовать «голый» Spring, т. е. только ту часть, которая называется IoC-контейнер, то достаточно подключить лишь spring-context.
Какие бывают контексты и как их создать?
У интерфейса ApplicationContext есть большое количество реализаций: — ClassPathXmlApplicationContext ; — FileSystemXmlApplicationContext ; — GenericGroovyApplicationContext ; — AnnotationConfigApplicationContext ; — и даже StaticApplicationContext ; — а также некоторые другие.
Они отличаются друг от друга именно тем, каким способом задаются мета-данные и где хранится эта конфигурация. Например: — ClassPathXmlApplicationContext — метаданные конфигурируются XML-файлом(-ами) и они лежат в classpath, т. е. в ресурсах модуля; — FileSystemXmlApplicationContext — метаданные тоже конфигурируются XML-файлом(-ами), но они находятся где-то в файловой системе, например, /etc/yourapp/spring-context.xml ; — AnnotationConfigApplicationContext — метаданные конфигурируются с помощью аннотаций прямо на классах.
Современным способом конфигурирования считаются аннотации ( AnnotationConfigApplicationContext ), дальше будем создавать именно их.
Приведём пример создания такого контекста в методе main:
Итого: создаём контекст.
Следите за новостями, оставляйте комментарии и посмотрите программу курса «Разработчик на Spring Framework», вдруг захочется погрузится полностью!
Java Spring несколько ApplicationContext
В соответствии с API spring ApplicationContext :
Центральный интерфейс для настройки конфигурации приложения. Это доступно только для чтения, пока приложение запущено, но может быть перезагружено, если реализация поддерживает это.
Корневой интерфейс для доступа к контейнеру spring bean. Это основной клиентский вид контейнера bean.
Сверху мои вопросы:
Сначала вы задаете вопросы:
1) Я продолжаю видеть в книге упомянутый «контейнер», к чему относится контейнер? Один контейнер означает один java-процесс? или один контейнер относится к одному объекту ApplicationContext?
2) Если я создаю два приложения ApplicationContext в одном приложении Java (один основной), являются ли эти два интерфейса одним центральным контейнером? Или два отдельных разных экземпляра? См. Код ниже, какова разница между context1 и context2? Если есть один синглтон в Beans.xml, он вызывается контекстом1 и context2, являются ли они двумя отдельными экземплярами или одним и тем же экземпляром?
ApplicationContext context1 = new ClassPaспасибоmlApplicationContext ( «Beans.xml» ); ApplicationContext context2 = new ClassPaспасибоmlApplicationContext ( «Beans.xml» ); >
С помощью этих instanciations вы получите 2 полностью независимых контекста приложения. Один bean, объявленный первым, не будет найден в другом.
Обычно в веб-приложении имеется более одного контекста приложения, поскольку Spring имеет понятие иерархии ApplicationContext. Вы можете объявить их как:
В контейнере они относятся к ядру spring Inversion of Control container. Контейнер обеспечивает способ инициализации/загрузки вашего приложения (загрузка конфигурации в xml файлах или аннотации) с помощью reflection и управление жизненным циклом Java объекты, которые называются beans или управляемыми объектами.
Во время этой начальной фазы у вас нет (как правило, еще возможно) управления в вашем приложении, вместо этого вы получите полностью инициализированное состояние для приложения, когда выполняется самозагрузка (или ничего, в случае его отказа),
Это замена или, возможно, дополнение к тому, что называется контейнером EJB3; тем не менее, spring при условии, что он не соответствует стандарту EJB. Исторически, внедрение EJB было ограничено сложностью этой спецификации, при этом spring был вновь созданным проектом для сопоставимых функций EJB3, работающих на jvm J2SE и без контейнера EJB, и с гораздо более легкой конфигурацией.
В соответствии с вашим вторым вопросом вы можете иметь несколько экземпляров ApplicationContexts, в этом случае они будут полностью изолированы, каждый со своей собственной конфигурацией.